streamalism.org

1. Oversikt

I denne veiledningen skal vi ta en titt på Jersey Test Framework og se hvordan vi kan bruke den til å raskt skrive integrasjonstester.

Som vi allerede har sett i tidligere artikler, Jersey er et open source-rammeverk for utvikling av RESTful Web Services. Vi kan lære mer om Jersey i vår introduksjon til å lage en API med Jersey og Spring-artikkelen - her.

2. Oppsett av program

Jersey Test Framework er et verktøy som hjelper oss med å verifisere riktig implementering av komponentene på serversiden. Som vi får se senere, det gir en rask og problemfri måte å skrive integrasjonstester på og kan håndtere kommunikasjon med HTTP API-ene våre veldig bra.

På samme måte fungerer det nesten out-of-the-box, og det er enkelt å integrere med våre Maven-baserte prosjekter. Rammeverket er primært basert på JUnit, selv om det er mulig å bruke det også med TestNG, noe som gjør det brukbart i nesten alle miljøer.

I neste avsnitt ser vi hvilke avhengigheter vi trenger å legge til i applikasjonen vår for å kunne bruke rammeverket.

2.1. Maven avhengigheter

Først av alt, la oss legge til kjerneavhengigheten til Jersey Test Framework pom.xml:

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

Som alltid kan vi få den nyeste versjonen fra Maven Central.

Nesten nesten alle Jersey-tester bruker defacto Grizzly testcontainerfabrikk, som vi også må legge til:

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

Igjen kan vi finne den nyeste versjonen i Maven Central.

3. Komme i gang

I denne neste delen vil vi dekke de grunnleggende trinnene som trengs for å skrive en enkel test.

Vi skal begynne med å teste det enkle Hilsener ressurs på serveren vår:

@Path ("/ greetings") public class Hilsen {@GET @Path ("/ hi") public String getHiGreeting () {return "hi"; }} 

3.1. Konfigurere testen

La oss nå definere testklassen vår:

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

Vi kan se i eksemplet ovenfor at for å utvikle en test ved hjelp av Jersey Test Framework, må testen vår underklasse JerseyTest.

Deretter overstyrer vi konfigurere metoden som returnerer en tilpasset ressurskonfigurasjon for testen vår og bare inneholder Hilsener ressurs. Dette er selvfølgelig ressursen vi ønsker å teste.

3.2. Skrive vår første test

La oss starte med å teste en enkel GET-forespørsel fra hilsen-API-et vårt:

@Test offentlig ugyldighet gittGetHiGreeting_whenCorrectRequest_thenResponseIsOkAndContainsHi () {Response response = target ("/ greetings / hi"). Forespørsel () .get (); assertEquals ("Http Response should be 200:", Status.OK.getStatusCode (), response.getStatus ()); assertEquals ("Http Content-Type should be:", MediaType.TEXT_HTML, response.getHeaderString (HttpHeaders.CONTENT_TYPE)); Strenginnhold = respons.readEntity (String.class); assertEquals ("Innholdet i ressponse er:", "hei", innhold); } 

Legg merke til at vi har full tilgang til HTTP-svaret - slik at vi kan gjøre ting som å sjekke statuskoden for å forsikre oss om at operasjonen faktisk var vellykket, eller jobbe med selve responsen.

La oss forklare mer detaljert hva vi gjør i eksemplet ovenfor:

1. Send en HTTP GET-forespørsel til ‘/ hilsener / hei '
2. Sjekk HTTP-statuskoden og innholdstypesvaroverskrifter
3. Test innholdet i svaret inneholder strengen “hei”

4. Testing GET for å hente ressurser

Nå som vi har sett de grunnleggende trinnene som er involvert i å lage tester. La oss teste den enkle Fruit API som vi introduserte i den utmerkede artikkelen om Jersey MVC Support.

4.1. Få vanlig JSON

I eksemplet nedenfor jobber vi med responsorganet som en standard JSON-streng:

@Test offentlig ugyldig givenFruitExists_whenSearching_thenResponseContainsFruit () {final String json = target ("fruit / search / strawberry"). Forespørsel () .get (String.class); assertThat (json, containString ("{\" name \ ": \" strawberry \ ", \" weight \ ": 20}")); }

4.2. Få enhet i stedet for JSON

Vi kan også kartlegge svaret direkte til en ressursenhetsklasse - for eksempel:

 @Test public void givenFruitExists_whenSearching_thenResponseContainsFruitEntity () {final Fruit entity = target ("fruit / search / strawberry"). Forespørsel () .get (Fruit.class); assertEquals ("Fruktnavn:", "jordbær", entity.getName ()); assertEquals ("Fruit weight:", Integer.valueOf (20), entity.getWeight ()); }

Denne gangen spesifiserer vi Java-typen svarenheten skal konverteres til i få metode - a Frukt gjenstand.

5. Testing av POST for å opprette ressurser

For å lage en ny ressurs i API-et vårt - vil vi gjøre god bruk av POST-forespørsler. I neste avsnitt vil vi se hvordan vi kan teste denne delen av API-en vår.

5.1. Post Plain JSON

La oss starte med å legge ut en vanlig JSON-streng for å teste opprettelsen av en ny fruktressurs:

@Test offentlig ugyldig gittCreateFruit_whenJsonIsCorrect_thenResponseCodeIsCreated () {Response response = target ("fruit / created"). Forespørsel () .post (Entity.json ("{\" name \ ": \" strawberry \ ", \" weight \ ": 20} ")); assertEquals ("Http Response should be 201", Status.CREATED.getStatusCode (), response.getStatus ()); assertThat (respons.readEntity (String.class), inneholderString ("Frukt lagret: Frukt [navn: jordbærfarge: null]")); }

I eksemplet ovenfor bruker vi post metode som tar en Enhet objektparameter. Vi bruker det praktiske json metode for å opprette en enhet fra den tilsvarende JSON-strengen.

5.2. Post Entity i stedet for JSON

Som vi allerede har sett med få forespørsler, kan vi også legge ut en ressursenhetsklasse direkte - for eksempel:

@Test offentlig tomrom gittCreateFruit_whenFruitIsInvalid_thenResponseCodeIsBadRequest () {Fruktfrukt = ny frukt ("Blåbær", "lilla"); frukt.settvekt (1); Svarrespons = mål ("frukt / opprett"). Forespørsel (MediaType.APPLICATION_JSON_TYPE) .post (Entity.entity (frukt, MediaType.APPLICATION_JSON_TYPE)); assertEquals ("Http Response should be 400", 400, response.getStatus ()); assertThat (respons.readEntity (String.class), inneholderString ("Fruktvekt må være 10 eller større")); }

Denne gangen bruker vi enhet metode for å legge ut fruktenheten vår og også spesifisere medietypen som JSON.

5.3. Skjemainnleveringer ved hjelp av POST

I vårt siste innleggseksempel vil vi se hvordan du tester skjemainnleveringer via en innleggsforespørsel:

@Test offentlig ugyldig givenCreateFruit_whenFormContainsNullParam_thenResponseCodeIsBadRequest () {Form form = new Form (); form.param ("navn", "eple"); form.param ("farge", null); Svarrespons = mål ("frukt / opprett"). Forespørsel (MediaType.APPLICATION_FORM_URLENCODED) .post (Entity.form (form)); assertEquals ("Http Response should be 400", 400, response.getStatus ()); assertThat (response.readEntity (String.class), inneholderString ("Fruktfarge må ikke være null")); }

På samme måte bruker vi Enhet klasse, men send denne gangen et skjema som inneholder en rekke parametere til innleggsforespørselen vår.

6. Testing av andre HTTP-verb

Noen ganger må vi teste andre HTTP-endepunkter som PUT og DELETE. Dette er selvfølgelig fullt mulig å bruke Jersey Test Framework.

La oss se et enkelt PUT-eksempel:

@Test offentlig ugyldig givenUpdateFruit_whenFormContainsBadSerialParam_thenResponseCodeIsBadRequest () {Form form = new Form (); form.param ("seriell", "2345-2345"); Svarrespons = mål ("frukt / oppdatering"). Forespørsel (MediaType.APPLICATION_FORM_URLENCODED) .put (Entity.form (form)); assertEquals ("Http Response should be 400", 400, response.getStatus ()); assertThat (response.readEntity (String.class), containString ("Frukt serienummer er ikke gyldig")); }

Når vi har ringt be om metode, kan vi påkalle hvilken som helst HTTP-metode på det gjeldende forespørselsobjektet.

7. Tilleggsfunksjoner

Jersey-testrammeverket inneholder en rekke ekstra konfigurasjonsegenskaper som kan hjelpe til med feilsøking og testing.

I neste eksempel ser vi hvordan man programmatisk aktiverer en funksjon med et gitt navn:

offentlig klasse FruitResourceIntegrationTest utvider JerseyTest {@ Override-beskyttet applikasjonskonfigurasjon () {aktiver (TestProperties.LOG_TRAFFIC); aktiver (TestProperties.DUMP_ENTITY); // ...

Når vi oppretter og konfigurerer Jersey-applikasjonen vår under test. Vi kan også aktivere flere egenskaper. I dette tilfellet aktiverer vi to loggeegenskaper - LOG_TRAFFIC og DUMP_ENTITYsom vil gi nyttig tilleggslogging og feilsøkingsinformasjon under testkjøringer.

8. Støttede containere

Som vi allerede har nevnt, er defacto-containeren som brukes når du skriver tester med Jersey Test Framework, Grizzly. Imidlertid støttes en rekke andre containere:

• In-Memory container
• HttpServer fra Oracle JDK
• Enkel beholder (org.simpleframework.http
• Bryggebeholder (org.eclipse.jetty)

For mer informasjon om hvordan du konfigurerer disse containerne, se dokumentasjonen her.

9. Konklusjon

For å oppsummere har vi i denne veiledningen utforsket Jersey Test Framework. Først begynte vi med å introdusere hvordan du konfigurerer Jersey Test Framework, og så så vi hvordan vi skulle skrive en test for et veldig enkelt API.

I neste avsnitt så vi hvordan vi skulle skrive tester for en rekke GET og POST API endepunkter. Til slutt så vi på noen ekstra funksjoner og containerne som Jersey Test Framework støtter.

Som alltid er hele kildekoden til artikkelen tilgjengelig på GitHub.