Stai testando un servizio Web JAX-RS?

Attualmente sto cercando modi per creare test automatizzati per un servizio web basato su JAX-RS (Java API for RESTful Web Services).

Fondamentalmente ho bisogno di un modo per inviargli determinati input e verificare di ottenere le risposte previste. Preferirei farlo tramite JUnit, ma non sono sicuro di come farlo.

Quale approccio utilizzi per testare i tuoi servizi web?

Aggiornamento: come ha sottolineato entzik, il disaccoppiamento del servizio Web dalla logica aziendale mi consente di eseguire un test unitario della logica aziendale. Tuttavia, voglio anche testare i codici di stato HTTP corretti, ecc.

Jersey è dotato di un'ottima API client RESTful che semplifica la scrittura di unit test. Vedi gli unit test negli esempi forniti con Jersey. Usiamo questo approccio per testare il supporto REST in Apache Camel , se sei interessato i casi di test sono qui

Puoi provare REST Assured che rende molto semplice testare i servizi REST e convalidare la risposta in Java (utilizzando JUnit o TestNG).

Come ha detto James; C'è built-in framework di test integrato per Jersey. Un semplice esempio di Hello World può essere così:

pom.xml per l'integrazione con Maven. Quando corri mvn test. I framework iniziano un contenitore grizzly. Puoi usare jetty o tomcat cambiando le dipendenze.

...
<dependencies>
  <dependency>
    <groupId>org.glassfish.jersey.containers</groupId>
    <artifactId>jersey-container-servlet</artifactId>
    <version>2.16</version>
  </dependency>

  <dependency>
    <groupId>org.glassfish.jersey.test-framework</groupId>
    <artifactId>jersey-test-framework-core</artifactId>
    <version>2.16</version>
    <scope>test</scope>
  </dependency>

  <dependency>
    <groupId>org.glassfish.jersey.test-framework.providers</groupId>
    <artifactId>jersey-test-framework-provider-grizzly2</artifactId>
    <version>2.16</version>
    <scope>test</scope>
  </dependency>
</dependencies>
...

ExampleApp.java

import javax.ws.rs.ApplicationPath;
import javax.ws.rs.core.Application;

@ApplicationPath("/")
public class ExampleApp extends Application {

}

HelloWorld.java

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

@Path("/")
public final class HelloWorld {

    @GET
    @Path("/hello")
    @Produces(MediaType.TEXT_PLAIN)
    public String sayHelloWorld() {

        return "Hello World!";
    }
}

HelloWorldTest.java

import org.glassfish.jersey.server.ResourceConfig;
import org.glassfish.jersey.test.JerseyTest;
import org.junit.Test;
import javax.ws.rs.core.Application;
import static org.junit.Assert.assertEquals;

public class HelloWorldTest extends JerseyTest {

    @Test
    public void testSayHello() {

        final String hello = target("hello").request().get(String.class);

        assertEquals("Hello World!", hello);
    }

    @Override
    protected Application configure() {

        return new ResourceConfig(HelloWorld.class);
    }
}

Puoi controllare questa applicazione di esempio.

Probabilmente hai scritto del codice java che implementa la tua logica aziendale e quindi hai generato l'endpoint dei servizi web per questo.

Una cosa importante da fare è testare in modo indipendente la logica aziendale. Poiché è puro codice java, puoi farlo con normali test JUnit.

Ora, poiché la parte dei servizi web è solo un punto finale, quello che vuoi assicurarti è che l'impianto idraulico generato (stub, ecc.) Sia sincronizzato con il tuo codice java. puoi farlo scrivendo test JUnit che invocano i client java del servizio web generato. Questo ti farà sapere quando modifichi le tue firme java senza aggiornare il materiale dei servizi web.

Se l'impianto idraulico dei servizi Web viene generato automaticamente dal sistema di compilazione ad ogni compilazione, potrebbe non essere necessario testare gli endpoint (supponendo che sia tutto generato correttamente). Dipende dal tuo livello di paranoia.

Sebbene sia troppo tardi dalla data di pubblicazione della domanda, ho pensato che questo potrebbe essere utile per altri che hanno una domanda simile. Jersey viene fornito con un framework di test denominato Jersey Test Framework che consente di testare il servizio Web RESTful, inclusi i codici di stato della risposta. Puoi usarlo per eseguire i tuoi test su contenitori leggeri come Grizzly, HTTPServer e / o EmbeddedGlassFish. Inoltre, il framework potrebbe essere utilizzato per eseguire i test su un normale contenitore web come GlassFish o Tomcat.

Uso HTTPClient di Apache (http://hc.apache.org/) per chiamare Restful Services. La libreria client HTTP ti consente di eseguire facilmente get, post o qualsiasi altra operazione di cui hai bisogno. Se il servizio utilizza JAXB per l'associazione xml, è possibile creare un JAXBContext per serializzare e deserializzare input e output dalla richiesta HTTP.

Dai un'occhiata al generatore di client di riposo Alchemy . Questo può generare un'implementazione proxy per la tua classe di servizio web JAX-RS utilizzando il client jersey dietro le quinte. Effettivamente ti chiamerai metodi webservice come semplici metodi java dai tuoi unit test. Gestisce anche l'autenticazione http.

Non è prevista la generazione di codice se è necessario eseguire semplicemente dei test, quindi è conveniente.

Dichiarazione di non responsabilità: sono l'autore di questa libreria.

Sii semplice. Dai un'occhiata a https://github.com/valid4j/http-matchers che possono essere importati da Maven Central.

    <dependency>
        <groupId>org.valid4j</groupId>
        <artifactId>http-matchers</artifactId>
        <version>1.0</version>
    </dependency>

Esempio di utilizzo:

// Statically import the library entry point:
import static org.valid4j.matchers.http.HttpResponseMatchers.*;

// Invoke your web service using plain JAX-RS. E.g:
Client client = ClientBuilder.newClient();
Response response = client.target("http://example.org/hello").request("text/plain").get();

// Verify the response
assertThat(response, hasStatus(Status.OK));
assertThat(response, hasHeader("Content-Encoding", equalTo("gzip")));
assertThat(response, hasEntity(equalTo("content")));
// etc...

Una cosa importante da fare è testare in modo indipendente la logica aziendale

Certamente non presumo che la persona che ha scritto il codice JAX-RS e sta cercando di testare l'interfaccia dell'interfaccia sia in qualche modo, per qualche motivo bizzarro e inspiegabile, ignaro dell'idea che lui o lei possa testare altre parti del programma, comprese le lezioni di logica aziendale. Non è affatto utile affermare l'ovvio e si è ripetutamente ribadito che anche le risposte devono essere testate.

Sia Jersey che RESTEasy hanno applicazioni client e nel caso di RESTEasy puoi usare gli stessi annunci (anche escludere l'interfaccia annotata e usarla sul lato client e server dei tuoi test).

NON RIPOSO quello che questo servizio può fare per te; RIPOSA cosa puoi fare per questo servizio.

Da quanto ho capito, lo scopo principale dell'autore di questo problema è di separare il livello JAX RS da quello aziendale. E unit test solo il primo. Qui dobbiamo risolvere due problemi fondamentali:

1. Esegui in prova alcuni server web / applicazioni, inserisci i componenti JAX RS in esso. E solo loro.
2. Servizi aziendali simulati all'interno dei componenti JAX RS / livello REST.

Il primo è risolto con Arquillian. Il secondo è perfettamente descritto in arquillicano e beffardo

Di seguito è riportato un esempio del codice, potrebbe differire se si utilizza un altro server delle applicazioni, ma spero che tu possa ottenere l'idea di base ei vantaggi.

import javax.inject.Inject;
import javax.ws.rs.GET;
import javax.ws.rs.Path;

import com.brandmaker.skinning.service.SomeBean;

/**
* Created by alexandr on 31.07.15.
*/
@Path("/entities")
public class RestBean
{
   @Inject
   SomeBean bean;

   @GET
   public String getEntiry()
   {
       return bean.methodToBeMoked();
   }
}

import java.util.Set;

import javax.ws.rs.ApplicationPath;
import javax.ws.rs.core.Application;

import com.google.common.collect.Sets;

/**
*/
@ApplicationPath("res")
public class JAXRSConfiguration extends Application
{
   @Override
   public Set<Class<?>> getClasses()
   {
       return Sets.newHashSet(RestBean.class);
   }
}


public class SomeBean
{
   public String methodToBeMoked()
   {
       return "Original";
   }
}

import javax.enterprise.inject.Specializes;

import com.brandmaker.skinning.service.SomeBean;

/**
*/
@Specializes
public class SomeBeanMock extends SomeBean
{
   @Override
   public String methodToBeMoked()
   {
       return "Mocked";
   }
}

@RunWith(Arquillian.class)
public class RestBeanTest
{
   @Deployment
   public static WebArchive createDeployment() {
       WebArchive war = ShrinkWrap.create(WebArchive.class, "test.war")
               .addClasses(JAXRSConfiguration.class, RestBean.class, SomeBean.class, SomeBeanMock.class)
               .addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
       System.out.println(war.toString(true));
       return war;
   }

   @Test
   public void should_create_greeting() {
       Client client = ClientBuilder.newClient();
       WebTarget target = client.target("http://127.0.0.1:8181/test/res/entities");
       //Building the request i.e a GET request to the RESTful Webservice defined
       //by the URI in the WebTarget instance.
       Invocation invocation = target.request().buildGet();
       //Invoking the request to the RESTful API and capturing the Response.
       Response response = invocation.invoke();
       //As we know that this RESTful Webserivce returns the XML data which can be unmarshalled
       //into the instance of Books by using JAXB.
       Assert.assertEquals("Mocked", response.readEntity(String.class));
   }
}

Un paio di note:

1. La configurazione JAX RS senza web.xml viene utilizzata qui.
2. Qui viene utilizzato il client JAX RS (non RESTEasy / Jersey, espongono API più convenienti)
3. Quando inizia il test, il corridore di Arquillian inizia a lavorare. Qui puoi trovare come configurare i test per Arquillian con il server delle applicazioni necessario.
4. A seconda del server delle applicazioni scelto, un URL nel test sarà leggermente diverso. È possibile utilizzare un'altra porta. 8181 è utilizzato da Glassfish Embedded nel mio esempio.

Spero che ti aiuti.