Ответ 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.
Некоторые ресурсы
Некоторые примеры
- Как написать Unit Test для этого класса с использованием тестовой среды Jersey 2
- Как тестировать блок памяти Spring-Jersey
- Пример с Mockito, тестовой платформой и Jersey 2
- Пример с Mockito, тестовой платформой и Джерси 1
ОБНОВИТЬ
Если вы не используете Maven, вот банки, вам нужно будет запустить встроенный контейнер Grizzly для теста на испытания в Джерси
Я обычно искать все мои баночки здесь. Вы можете выбрать версию и на следующей странице должна быть ссылка для загрузки. Вы можете использовать панель поиска для поиска других.
Вот простой пример, когда у вас есть все банки
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. Если вы знакомы с Джерси-клиентом, то этот класс не должен быть для вас новым.