Comment tester un Maillot de services web REST?

Si vous voulez tester à l'aide de l'URL, alors vous aurez besoin pour démarrer un serveur de test. Vous pouvez démarrer explicitement un serveur embarqué, ce qui est assez commun pour les tests. Quelque chose comme

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

C'est essentiellement un test d'intégration. Vous êtes à la Grizzly conteneur et le chargement d'une ResourceConfig le serveur avec uniquement le Service classe. Bien sûr, vous pourriez ajouter des classes à la configuration. Vous pouvez utiliser les "vrais" des ressources de la configuration, si vous le souhaitez.

Le test ci-dessus utilise cette dépendance

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

Une autre option, qui est celle que je préfère, est de faire usage de la Maillot Framework De Test, qui va démarrer un conteneur embarqué pour vous. Un test pourrait ressembler à quelque chose de plus comme

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

À l'aide de cette dépendance

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

Et intégré Grizzly conteneur va commencer sous le capot, avec votre ResourceConfig de configuration. Dans les deux exemples ci-dessus, il est supposé que le @Path de la valeur pour l' Service classe est service, comme vous pouvez le voir dans le test d'Url.

Certaines Ressources

• Maillot 2 Framework de Test guide de l'utilisateur

Quelques Exemples

• Comment écrire de Test de l'Unité de cette classe à l'aide de Jersey 2 framework de test
• Comment en mémoire de l'unité de test de Printemps-Jersey
• Exemple avec Mockito, Framework de Test, et Jersey 2
• Exemple avec Mockito, Framework de Test, et de Jersey 1

---

Mise à JOUR

Si vous n'êtes pas à l'aide de Maven, voici les pots que vous aurez besoin pour exécuter un embedded Grizzly conteneur pour le Maillot de Test Fraemwork

J'ai l'habitude de rechercher tous mes pots ici. Vous pouvez sélectionner la version et il devrait y avoir un lien dans la page suivante, pour le téléchargement. Vous pouvez utiliser la barre de recherche pour rechercher les autres.

Voici un simple exemple, une fois que vous avez tous les pots

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

Vous êtes probablement ne va pas avoir les ressources et ResourceConfig dans la même classe que le test, mais je veux juste garder les choses simples et visibles que dans une seule classe.

Si vous utilisez un web.xml ou un ResourceConfig sous-classe (comme illustré ci-dessus), vous pouvez couper ce que vous test en utilisant un autre ResourceConfig, construit dans la classe de test, comme je l'ai fait. Sinon, si vous utilisez votre normal ResourceConfig de classe, vous pouvez simplement le remplacer dans le configure méthode.

La configure méthode, c'est la construction d'un web.xml fichier, juste dans du code Java. Vous pouvez voir les différentes méthodes dans le WebAppDescriptor.Builder, comme initParam, qui est la même que pour un <init-param> dans votre site web xml. Vous pouvez simplement utiliser la chaîne de caractères dans les arguments, mais il y a certaines constantes, que j'ai utilisé ci-dessus.

La @Test est vous l'habitude de test JUnit qui va l'exécuter. C'est à l'aide de la Jersey Client. Mais au lieu de créer de la Client, vous pouvez simplement utiliser le préconfiguré Client par le simple accès à la resource() méthode, qui renvoie un WebResource. Si vous êtes familier avec le Maillot du Client, puis cette classe ne devrait pas être nouveau pour vous.

OriginalL'auteur Paul Samsotha

Je pense que @peeskillet vous a donné les prérequis de la compilation, j'.e vous avez besoin pour exécuter votre site web-le service d'un serveur web intégré. Vous pouvez également regarder dans dropwizard ou printemps-prise en charge du démarrage pour ce faire commodément.

Que pour, en fait, la vérification de la réponse j'aimerais faire simple et aller avec JUnit & http-rapprochement (voir https://github.com/valid4j/http-matchers)

OriginalL'auteur keyoxy