Как протестировать веб-сервис Джерси REST?

Я написал Restful Web-сервис и должен его протестировать с помощью JUnit4. Я уже написал клиент, использующий Джерси-клиент. Но хочу знать, могу ли я проверить свои услуги только с помощью junit4. Может кто-нибудь помочь мне с образцом, по крайней мере.

Мой сервис отдыха имеет метод аутентификации, который принимает имя пользователя, пароль и возвращает токен.

Я написал тестовый пример для метода проверки подлинности. Но я не уверен, как тестировать с помощью URL.

public class TestAuthenticate {
    Service service  = new Service();
    String username = "user";
    String password = "password";
    String token;

    @Test(expected = Exception.class)
    public final void testAuthenticateInputs() {
        password = "pass";
        service.authenticate(username, password);
    }

    @Test(expected = Exception.class)
    public final void testAuthenticateException(){
        username = null;
        String token = service.authenticate(username, password);
        assertNotNull(token);
    }

    @Test
    public final void testAuthenticateResult() {
        String token = service.authenticate(username, password);
        assertNotNull(token);
    }
}

ОТВЕТЫ

Ответ 1

Если вы хотите протестировать с помощью URL-адреса, вам нужно будет запустить сервер из своего теста. Вы можете явно запустить встроенный сервер, что довольно часто встречается для тестов. Что-то вроде

public class MyResourceTest {

    public static final String BASE_URI = "http://localhost:8080/api/";
    private HttpServer server;

    @Before
    public void setUp() throws Exception {
        final ResourceConfig rc = new ResourceConfig(Service.class);
        server = GrizzlyHttpServerFactory.createHttpServer(URI.create(BASE_URI), rc);       
    }

    @After
    public void tearDown() throws Exception {
        server.stop();
    }

    @Test
    public void testService() {
        Client client = ClientBuilder.newClient();
        WebTarget target = client.target(BASE_URI).path("service");
        ...
    }
}

Это в основном интеграционный тест. Вы запускаете контейнер Grizzly и загружаете ResourceConfig на сервер только с классом Service. Конечно, вы можете добавить в конфигурацию еще несколько классов. Вы можете использовать "реальную" конфигурацию ресурсов, если хотите.

Вышеупомянутый тест использует эту зависимость

<dependency>
    <groupId>org.glassfish.jersey.containers</groupId>
    <artifactId>jersey-container-grizzly2-http</artifactId>
    <version>${jersey2.version}</version>
</dependency>

Другой вариант, который я предпочитаю, заключается в использовании тестовой платформы Jersey, которая запустит для вас встроенный контейнер. Тест может выглядеть примерно как

public class SimpleTest extends JerseyTest {

    @Override
    protected Application configure() {
        return new ResourceConfig(Service.class);
    }

    @Test
    public void test() {
        String hello = target("service").request().get(String.class);
    }
}

Используя эту зависимость

<dependency>
    <groupId>org.glassfish.jersey.test-framework.providers</groupId>
    <artifactId>jersey-test-framework-provider-grizzly2</artifactId>
    <version>${jersey2.version}</version>
    <scope>test</scope>
</dependency>

И встроенный контейнер Grizzly начнет работать под капотом, с вашей конфигурацией ResourceConfig. В обоих примерах выше предполагается, что значение @Path для класса Service является service, как вы можете видеть в тестовых URL.

Некоторые ресурсы

Некоторые примеры

ОБНОВИТЬ

Если вы не используете Maven, вот банки, вам нужно будет запустить встроенный контейнер Grizzly для теста на испытания в Джерси

enter image description here

Я обычно искать все мои баночки здесь. Вы можете выбрать версию и на следующей странице должна быть ссылка для загрузки. Вы можете использовать панель поиска для поиска других.

Вот простой пример, когда у вас есть все банки

import com.sun.jersey.api.client.WebResource;
import com.sun.jersey.api.core.DefaultResourceConfig;
import com.sun.jersey.spi.container.servlet.WebComponent;
import com.sun.jersey.test.framework.JerseyTest;
import com.sun.jersey.test.framework.WebAppDescriptor;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import junit.framework.Assert;
import org.junit.Test;

public class SimpleTest extends JerseyTest {

    @Path("service")
    public static class Service {
        @GET
        public String getTest() { return "Hello World!"; }
    }

    public static class AppConfig extends DefaultResourceConfig {
        public AppConfig() {
            super(Service.class);
        }
    }

    @Override
    public WebAppDescriptor configure() {
        return new WebAppDescriptor.Builder()
                .initParam(WebComponent.RESOURCE_CONFIG_CLASS, 
                           AppConfig.class.getName())
                .build();
    }

    @Test
    public void doTest() {
        WebResource resource = resource().path("service");
        String result = resource.get(String.class);
        Assert.assertEquals("Hello World!", result);
        System.out.println(result);
    }
}

У вас, скорее всего, не будет ресурсов и ResourceConfig в том же классе, что и тест, но я просто хочу сохранить его простым и все видимым в одном классе.

Если вы используете подкласс web.xml или ResourceConfig (как показано выше), вы можете сократить то, что вы тестируете, используя отдельный ResourceConfig, встроенный в тестовый класс, как я уже делал. В противном случае, если вы используете обычный класс ResourceConfig, вы можете просто заменить его в методе configure.

Метод configure в значительной степени просто создает файл web.xml, как раз в Java-коде. Вы можете увидеть различные методы в WebAppDescriptor.Builder, такие как initParam, который является таким же, как <init-param> в вашем веб-xml. Вы можете просто использовать строку в аргументах, но есть некоторые константы, как я использовал выше.

@Test - это обычный тест JUnit, который будет работать. Он использует Джерси-клиент. Но вместо создания Client вы можете просто использовать предварительно сконфигурированный Client, просто обратившись к методу resource(), который возвращает WebResource. Если вы знакомы с Джерси-клиентом, то этот класс не должен быть для вас новым.

Ответ 2

Посмотрите генератор поколений алхимиков. Это может привести к реализации прокси для вашего веб-сервиса JAX-RS, используя jersey-клиент за сценой. Эффективно вы будете называть вас методами webservice как простые java-методы из ваших модульных тестов. Также обрабатывает HTTP-аутентификацию.

Нет необходимости генерировать код, если вам нужно просто запускать тесты, чтобы это было удобно.

Демо настраивает гризли и использует генератор выше для запуска тестов юнита.

Отказ от ответственности: я являюсь автором этой библиотеки.

Ответ 3

Я думаю, что @peeskillet предоставил вам необходимые предварительные условия, то есть вам нужно запустить веб-сервис на встроенном веб-сервере. Вы также можете заглянуть в поддержку dropwizard или spring -boot для этого удобно.

Что касается фактической проверки ответа, я бы оставил его простым и пошел с JUnit и http-matchers (см. https://github.com/valid4j/http-matchers)