streamalism.org

1. Oversigt

I denne vejledning skal vi se på Jersey Test Framework og se, hvordan vi kan bruge den til hurtigt at skrive integrationstest.

Som vi allerede har set i tidligere artikler, Jersey er en open source-ramme til udvikling af RESTful Web Services. Vi kan lære mere om Jersey i vores introduktion til at oprette en API med Jersey og Spring-artiklen - her.

2. Opsætning af applikation

Jersey Test Framework er et værktøj, der hjælper os med at verificere den korrekte implementering af vores serversides komponenter. Som vi får se senere, det giver en hurtig og problemfri måde at skrive integrationstest på og kan håndtere kommunikation med vores HTTP API'er meget godt.

Ligeledes fungerer det næsten out-of-the-box, og det er nemt at integrere med vores Maven-baserede projekter. Rammen er primært baseret på JUnit, selvom det også er muligt at bruge det med TestNG, hvilket gør det anvendeligt i næsten alle miljøer.

I det næste afsnit ser vi, hvilke afhængigheder vi skal tilføje til vores applikation for at kunne bruge rammen.

2.1. Maven afhængigheder

Lad os først og fremmest tilføje Jersey Test Framework's kerneafhængighed til vores pom.xml:

 org.glassfish.jersey.test-framework jersey-test-framework-core 2.27 test 

Som altid kan vi få den nyeste version fra Maven Central.

Næsten næsten alle Jersey-tests bruger defacto Grizzly-testcontainerfabrikken, som vi også skal tilføje:

 org.glassfish.jersey.test-framework.providers jersey-test-framework-provider-grizzly2 2.27 test 

Igen kan vi finde den nyeste version i Maven Central.

3. Kom godt i gang

I dette næste afsnit dækker vi de grundlæggende trin, der er nødvendige for at skrive en simpel test.

Vi begynder med at teste det enkle Vær hilset ressource på vores server:

@Path ("/ greetings") offentlig klasse Hilsner {@GET @Path ("/ hi") public String getHiGreeting () {returner "hi"; }} 

3.1. Konfiguration af testen

Lad os nu definere vores testklasse:

offentlig klasse GreetingsResourceIntegrationTest udvider JerseyTest {@ Override beskyttet Application configure () {return new ResourceConfig (Greetings.class); } // ...} 

Vi kan se i ovenstående eksempel, at vores test skal underklasse for at udvikle en test ved hjælp af Jersey Test Framework JerseyTest.

Dernæst tilsidesætter vi konfigurere metode, der returnerer en tilpasset ressourcekonfiguration til vores test og kun indeholder Vær hilset ressource. Dette er selvfølgelig den ressource, vi ønsker at teste.

3.2. Skrivning af vores første test

Lad os starte med at teste en simpel GET-anmodning fra vores hilsen-API:

@Test offentlig ugyldighed givenGetHiGreeting_whenCorrectRequest_thenResponseIsOkAndContainsHi () {Response response = target ("/ greetings / hi"). Anmodning () .get (); assertEquals ("Http-svar skal være 200:", Status.OK.getStatusCode (), respons.getStatus ()); assertEquals ("Http Content-Type should be:", MediaType.TEXT_HTML, response.getHeaderString (HttpHeaders.CONTENT_TYPE)); Strengindhold = respons.readEntity (String.class); assertEquals ("Indholdet af ressponse er:", "hej", indhold); } 

Bemærk, at vi har fuld adgang til HTTP-svaret - så vi kan gøre ting som at kontrollere statuskoden for at sikre, at operationen faktisk var vellykket, eller arbejde med selve reaktionens krop.

Lad os forklare mere detaljeret, hvad vi gør i ovenstående eksempel:

1. Send en HTTP GET-anmodning til ‘/ hilsner / hej’
2. Tjek HTTP-statuskoden og indholdstype-svaroverskrifter
3. Test indholdet af svaret indeholder strengen “hej”

4. Test af GET for at hente ressourcer

Nu, hvor vi har set de grundlæggende trin involveret i oprettelse af tests. Lad os teste den enkle Fruit API, som vi introducerede i den fremragende Jersey MVC Support-artikel.

4.1. Få almindelig JSON

I nedenstående eksempel arbejder vi med responsorganet som en standard JSON-streng:

@Test offentlig ugyldighed givenFruitExists_whenSearching_thenResponseContainsFruit () {final String json = target ("fruit / search / strawberry"). Anmodning () .get (String.class); assertThat (json, containString ("{\" navn \ ": \" jordbær \ ", \" vægt \ ": 20}")); }

4.2. Få enhed i stedet for JSON

Vi kan også kortlægge svaret direkte til en klasse ressourceenhed - for eksempel:

 @Test offentlig ugyldighed givenFruitExists_whenSearching_thenResponseContainsFruitEntity () {final Fruit entity = target ("fruit / search / strawberry"). Anmodning () .get (Fruit.class); assertEquals ("Frugtnavn:", "jordbær", entity.getName ()); assertEquals ("Frugtvægt:", Integer.valueOf (20), entity.getWeight ()); }

Denne gang specificerer vi den Java-type, som svarenheden konverteres til i få metode - a Frugt objekt.

5. Test af POST for at skabe ressourcer

For at oprette en ny ressource i vores API - bruger vi god POST-anmodninger. I det næste afsnit vil vi se, hvordan vi tester denne del af vores API.

5.1. Post Plain JSON

Lad os starte med at sende en almindelig JSON-streng for at teste oprettelsen af ​​en ny frugtressource:

@Test offentlig ugyldighed givenCreateFruit_whenJsonIsCorrect_thenResponseCodeIsCreated () {Response response = target ("fruit / created"). Anmodning () .post (Entity.json ("{\" name \ ": \" jordbær \ ", \" vægt \ ": 20} ")); assertEquals ("Http-svar skal være 201", Status.CREATED.getStatusCode (), respons.getStatus ()); assertThat (respons.readEntity (String.class), containString ("Frugt gemt: Frugt [navn: jordbærfarve: null]")); }

I ovenstående eksempel bruger vi stolpe metode, der tager en Enhed objektparameter. Vi bruger det praktiske json metode til at oprette en enhed ud fra den tilsvarende JSON-streng.

5.2. Postenhed i stedet for JSON

Som vi allerede har set med få anmodninger, kan vi også sende en klasse for ressourceenheder direkte - for eksempel:

@Test offentlig ugyldighed givenCreateFruit_whenFruitIsInvalid_thenResponseCodeIsBadRequest () {Frugtfrugt = ny frugt ("Blåbær", "lilla"); fruit.setWeight (1); Svarrespons = mål ("frugt / opret"). Anmodning (MediaType.APPLICATION_JSON_TYPE) .post (Entity.entity (fruit, MediaType.APPLICATION_JSON_TYPE)); assertEquals ("Http-svar skal være 400", 400, respons.getStatus ()); assertThat (respons.readEntity (String.class), indeholderString ("Frugtvægt skal være 10 eller større")); }

Denne gang bruger vi enhed metode til at poste vores Fruit-enhed og angive også medietypen som JSON.

5.3. Formularindsendelser ved hjælp af POST

I vores sidste posteksempel vil vi se, hvordan man tester formularindsendelser via en postanmodning:

@Test offentlig ugyldighed givenCreateFruit_whenFormContainsNullParam_thenResponseCodeIsBadRequest () {Form form = new Form (); form.param ("navn", "æble"); form.param ("farve", null); Svarrespons = mål ("frugt / opret"). Anmodning (MediaType.APPLICATION_FORM_URLENCODED) .post (Entity.form (form)); assertEquals ("Http-svaret skal være 400", 400, respons.getStatus ()); assertThat (response.readEntity (String.class), containString ("Frugtfarven må ikke være nul")); }

På samme måde gør vi brug af Enhed klasse, men send denne gang en formular, der indeholder et antal parametre til vores postanmodning.

6. Test af andre HTTP-verb

Nogle gange er vi nødt til at teste andre HTTP-slutpunkter som PUT og DELETE. Dette er naturligvis perfekt muligt ved hjælp af Jersey Test Framework.

Lad os se et simpelt PUT-eksempel:

@Test offentlig ugyldighed givenUpdateFruit_whenFormContainsBadSerialParam_thenResponseCodeIsBadRequest () {Form form = new Form (); form.param ("seriel", "2345-2345"); Svarrespons = mål ("frugt / opdatering"). Anmodning (MediaType.APPLICATION_FORM_URLENCODED) .put (Entity.form (form)); assertEquals ("Http-svar skal være 400", 400, respons.getStatus ()); assertThat (respons.readEntity (String.class), indeholderString ("Frugts serienummer er ikke gyldigt")); }

Når vi har ringet til anmodning metode, kan vi påkalde enhver HTTP-metode på det aktuelle anmodningsobjekt.

7. Yderligere funktioner

Jersey-testrammen indeholder en række yderligere konfigurationsegenskaber, som kan hjælpe med fejlfinding og test.

I det næste eksempel ser vi, hvordan man programmatisk aktiverer en funktion med et givet navn:

offentlig klasse FruitResourceIntegrationTest udvider JerseyTest {@ Override-beskyttet applikationskonfiguration () {aktiv (TestProperties.LOG_TRAFFIC); aktiver (TestProperties.DUMP_ENTITY); // ...

Når vi opretter og konfigurerer vores Jersey-applikation under test. Vi kan også aktivere yderligere egenskaber. I dette tilfælde aktiverer vi to loggeegenskaber - LOG_TRAFFIC og DUMP_ENTITYsom vil give nyttige yderligere logning- og fejlretningsoplysninger under testkørsler.

8. Understøttede containere

Som vi allerede har nævnt, er defacto-containeren, der blev brugt til at skrive tests med Jersey Test Framework, Grizzly. Dog understøttes et antal andre containere:

• Beholder til hukommelse
• HttpServer fra Oracle JDK
• Enkel beholder (org.simpleframework.http
• Anløbsbrocontainer (org.eclipse.jetty)

For mere information om, hvordan du konfigurerer disse containere, se dokumentationen her.

9. Konklusion

For at opsummere har vi i denne vejledning undersøgt Jersey Test Framework. Først startede vi med at introducere, hvordan man konfigurerer Jersey Test Framework, og så så, hvordan man skriver en test til en meget enkel API.

I det næste afsnit så vi, hvordan man skriver tests til en række GET- og POST API-slutpunkter. Endelig så vi på nogle ekstra funktioner og de containere, som Jersey Test Framework understøtter.

Som altid er artiklens fulde kildekode tilgængelig på GitHub.