it-swarm.com.de

Wie teste ich ein Jersey? REST Internetservice?

Ich habe einen Restful-Webdienst geschrieben und muss ihn mit JUnit4 testen. Ich habe bereits einen Client geschrieben, der Jersey Client verwendet. Will aber wissen, ob ich meinen Service nur mit junit4 testen kann. Kann mir wenigstens jemand mit Probe helfen. 

Mein Restdienst verfügt über eine Authentifizierungsmethode, die Benutzername, Kennwort und ein Token zurückgibt. 

Ich habe einen Testfall für die Authentifizierungsmethode geschrieben. Ich bin mir jedoch nicht sicher, wie ich mit URL testen sollte.

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

Wenn Sie mit der URL testen möchten, müssen Sie einen Server von Ihrem Test aus starten. Sie können explizit einen eingebetteten Server starten, was für Tests häufig vorkommt. So etwas wie

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

Es ist im Grunde ein Integrationstest. Sie starten den Grizzly-Container und laden eine ResourceConfig mit der Klasse Service auf den Server. Natürlich können Sie der Konfiguration weitere Klassen hinzufügen. Sie können "echte" Ressource-Konfiguration verwenden, wenn Sie wollten.

Der obige Test verwendet diese Abhängigkeit

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

Eine andere Option, die ich vorziehen würde, ist die Verwendung des Jersey Test Framework , das einen eingebetteten Container für Sie startet. Ein Test könnte mehr aussehen

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

Verwendung dieser Abhängigkeit

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

Der eingebettete Grizzly-Container wird mit Ihrer ResourceConfig-Konfiguration unter der Haube gestartet. In beiden obigen Beispielen wird davon ausgegangen, dass der @Path-Wert für die Service-Klasse service ist, wie Sie in den Test-URLs sehen können. 

Einige Ressourcen

Einige Beispiele


AKTUALISIEREN

Wenn Sie Maven nicht verwenden, werden hier die Gläser angegeben, die Sie benötigen, um einen eingebetteten Grizzly-Container für die Jersey Test Fraemwork auszuführen

enter image description here

Normalerweise suche ich alle meine Gläser hier . Sie können die Version auswählen und auf der nächsten Seite sollte ein Link zum Herunterladen vorhanden sein. Sie können die Suchleiste verwenden, um nach den anderen zu suchen.

Hier ist ein einfaches laufendes Beispiel, sobald Sie alle Gläser haben

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

Wahrscheinlich werden Sie die Ressourcen und ResourceConfig nicht in derselben Klasse wie der Test haben, aber ich möchte es einfach und alles in einer Klasse sichtbar halten. 

Unabhängig davon, ob Sie eine web.xml- oder eine ResourceConfig-Unterklasse verwenden (wie oben gezeigt), können Sie das, was Sie testen, durch Verwendung einer separaten ResourceConfig, die in der Testklasse erstellt wurde, reduzieren. Andernfalls, wenn Sie Ihre normale ResourceConfig-Klasse verwenden, können Sie sie einfach in der configure-Methode ersetzen. 

Die configure-Methode besteht im Wesentlichen aus dem Erstellen einer web.xml-Datei nur in Java-Code. Sie können verschiedene Methoden in WebAppDescriptor.Builder sehen, wie initParam, die mit einem <init-param> in Ihrer Web-XML identisch sind. Sie können die Zeichenfolge einfach in den Argumenten verwenden, aber es gibt einige Konstanten, wie ich sie oben verwendet habe.

Der @Test ist der übliche JUnit-Test, der ausgeführt wird. Es verwendet den Jersey-Client. Anstatt die Client zu erstellen, können Sie einfach die vorkonfigurierte Client verwenden, indem Sie einfach auf die resource()-Methode zugreifen, die eine WebResource zurückgibt. Wenn Sie mit dem Jersey-Client vertraut sind, sollte diese Klasse für Sie nicht neu sein.

20
Paul Samsotha

Ich denke, @peeskillet hat Ihnen die notwendigen Voraussetzungen gegeben, d. H. Sie müssen Ihren Web-Service auf einem eingebetteten Webserver ausführen. Sie können auch die Dropwizard- oder Spring-Boot-Unterstützung in Erfahrung bringen.

Um die Antwort tatsächlich zu überprüfen, würde ich es einfach halten und mit JUnit & http-matchers gehen (siehe https://github.com/valid4j/http-matchers ).

0
keyoxy

Werfen Sie einen Blick auf Alchemy Rest Client Generator . Dadurch kann eine Proxy-Implementierung für Ihre JAX-RS-Webservice-Klasse generiert werden, indem der Jersey-Client hinter den Kulissen verwendet wird. Sie rufen Ihre Webservice-Methoden effektiv als einfache Java-Methoden aus Ihren Unit-Tests auf. Verarbeitet auch die HTTP-Authentifizierung.

Es ist keine Codegenerierung erforderlich, wenn Sie Tests einfach ausführen müssen, um eine bequeme Bedienung zu gewährleisten.

Die Demo hier grizzly einrichten und mit dem Generator oben Junit-Tests ausführen.

Haftungsausschluss: Ich bin der Autor dieser Bibliothek.

0
Ashish Shinde