¿Cómo probar un servicio web REST de Jersey?

He escrito un servicio web tranquilo y tengo que probarlo usando JUnit4. Ya he escrito un Cliente usando Jersey Client. Pero quiero saber si puedo probar mi servicio solo con junit4. Alguien me puede ayudar con la muestra al menos.

Mi servicio de reposo tiene un método de autenticación que toma el nombre de usuario, la contraseña y devuelve un token.

He escrito el caso de prueba para el método de autenticación. Pero no estoy seguro de cómo probar el uso de la 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); } } 

Si desea probar usando la URL, necesitará iniciar un servidor a partir de su prueba. Puede iniciar explícitamente un servidor incrustado, que es bastante común para las pruebas. Algo como

 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"); ... } } 

Básicamente es una prueba de integración. Está iniciando el contenedor Grizzly y cargando ResourceConfig en el servidor con solo la clase de Service . Por supuesto, podría agregar más clases a la configuración. Puede usar la configuración de recursos “real” si lo desea.

La prueba anterior usa esta dependencia

  org.glassfish.jersey.containers jersey-container-grizzly2-http ${jersey2.version}  

Otra opción, que es la que prefiero, es hacer uso del Jersey Test Framework , que comenzará un contenedor integrado para usted. Una prueba puede parecerse más a

 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); } } 

Usando esta dependencia

  org.glassfish.jersey.test-framework.providers jersey-test-framework-provider-grizzly2 ${jersey2.version} test  

Y el contenedor Grizzly integrado comenzará bajo el capó, con su configuración de ResourceConfig . En ambos ejemplos, se supone que el valor de @Path para la clase de service es el service , como puede ver en las URL de prueba.

Algunos recursos

  • Guía de usuario de Jersey 2 Test Framework

Algunos ejemplos

  • Cómo escribir la Prueba de Unidad para esta clase usando el marco de prueba de Jersey 2
  • Cómo prueba en la unidad de memoria Spring-Jersey
  • Ejemplo con Mockito, Test Framework y Jersey 2
  • Ejemplo con Mockito, Test Framework y Jersey 1

ACTUALIZAR

Si no está usando Maven, aquí están los flasks que necesitará para ejecutar un contenedor Grizzly incrustado para el Jersey Test Fraemwork

enter image description here

Por lo general, busco todos mis flasks aquí . Puede seleccionar la versión y debe haber un enlace en la página siguiente para descargar. Puede usar la barra de búsqueda para buscar los demás.

Aquí hay un ejemplo de ejecución simple, una vez que tenga todos los flasks

 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); } } 

Lo más probable es que no tenga los recursos y ResourceConfig en la misma clase que la prueba, pero solo quiero mantenerlo simple y todo visible en una sola clase.

Si está utilizando una subclase web.xml o ResourceConfig (como se muestra arriba), puede reducir lo que prueba utilizando un ResourceConfig separado, integrado en la clase de prueba, como lo he hecho. De lo contrario, si está utilizando su clase ResourceConfig normal, puede simplemente reemplazarla en el método de configure .

El método de configure , básicamente consiste en crear un archivo web.xml, solo en código Java. Puede ver diferentes métodos en WebAppDescriptor.Builder , como initParam , que es lo mismo que un en su web xml. Simplemente puede usar la cadena en los argumentos, pero hay algunas constantes, como he usado anteriormente.

El @Test es tu prueba JUnit habitual que se ejecutará. Está utilizando Jersey Client. Pero en lugar de crear el Client , simplemente puede usar el Client preconfigurado accediendo al método resource() , que devuelve un WebResource . Si está familiarizado con Jersey Client, esta clase no debería ser nueva para usted.

Eche un vistazo al generador de cliente de reposo Alchemy . Esto puede generar una implementación proxy para su clase de servicio web JAX-RS utilizando el cliente jersey detrás de la escena. Efectivamente, usted llamará sus métodos de servicio web como métodos simples de java de las pruebas de su unidad. Maneja la autenticación http también.

No hay generación de código involucrada si necesita simplemente ejecutar pruebas para que sea conveniente.

La demostración aquí configura grizzly y usa el generador anterior para ejecutar pruebas junit.

Descargo de responsabilidad: soy el autor de esta biblioteca.

Creo que @peeskillet te ha dado los requisitos previos necesarios, es decir, necesitas ejecutar tu servicio web en un servidor web incorporado. También puede consultar el soporte de Dropwizard o Spring-boot para hacer esto cómodamente.

En cuanto a la verificación de la respuesta, lo mantendría simple e iría con JUnit & http-matchers (ver https://github.com/valid4j/http-matchers )