Integrasjonstesting med Maven

1. Oversikt

Maven er det mest populære byggeverktøyet i Java-rommet, mens integrasjonstesting er en viktig del av utviklingsprosessen. Derfor, det er et naturlig valg å konfigurere og utføre integrasjonstester med Maven.

I denne opplæringen går vi over en rekke forskjellige måter å bruke Maven til integrasjonstesting og å skille integrasjonstester fra enhetstester.

2. Forberedelse

For å gjøre demonstrasjonskoden nær et ekte prosjekt, setter vi opp en JAX-RS-applikasjon. Dette programmet distribueres til en server før gjennomføring av integrasjonstester og demonteres etterpå.

2.1. Maven-konfigurasjon

Vi bygger vår REST-applikasjon rundt Jersey - referanseimplementeringen av JAX-RS. Denne implementeringen krever et par avhengigheter:

 org.glassfish.jersey.containers jersey-container-servlet-core 2.27 org.glassfish.jersey.inject jersey-hk2 2.27 

Vi finner de nyeste versjonene av disse avhengighetene her og her.

Vi bruker Jetty Maven-plugin for å sette opp et testmiljø. Denne plugin-en starter en bryggeserver i løpet av pre-integrasjon-test fase av Maven bygge livssyklus, og stopper den i post-integrasjon-test fase.

Slik konfigurerer vi Jetty Maven-plugin-modulen pom.xml:

 org.eclipse.jetty jetty-maven-plugin 9.4.11.v20180605 8999 avslutte 9000 start-brygge pre-integrasjon-test start stopp-brygge post-integrasjon-test stopp 

Når Jetty-serveren starter, vil den lytte på porten 8999. De stopKey og stopPort konfigurasjonselementer brukes utelukkende av plugin-modulene Stoppe mål og deres verdi er ikke viktig fra vårt perspektiv.

Her er hvor du finner den nyeste versjonen av Jetty Maven-plugin.

En annen ting å legge merke til er at vi må stille inn emballasje element i pom.xml fil til krig, ellers kan ikke Jetty-pluginet starte serveren:

krig

2.2. Opprette en REST-applikasjon

Applikasjonens endepunkt er veldig enkelt - det returneres en velkomstmelding når en GET-forespørsel treffer kontekstens rot:

@Path ("/") offentlig klasse RestEndpoint {@GET public String hei () {return "Velkommen til Baeldung!"; }}

Slik registrerer vi endepunktklassen hos Jersey:

pakke com.baeldung.maven.it; importer org.glassfish.jersey.server.ResourceConfig; offentlig klasse EndpointConfig utvider ResourceConfig {public EndpointConfig () {register (RestEndpoint.class); }}

For å ha Jetty-serveren oppmerksom på REST-applikasjonen vår, kan vi bruke en klassiker web.xml distribusjonsbeskrivelse:

  rest-servlet org.glassfish.jersey.servlet.ServletContainer javax.ws.rs.Application com.baeldung.maven.it.EndpointConfig rest-servlet / * 

Denne beskrivelsen må plasseres i katalogen / src / main / webapp/ WEB-INF å bli gjenkjent av serveren.

2.3. Testkode på klientsiden

Alle testklasser i de følgende avsnittene inneholder en enkelt metode:

@Test offentlig ugyldig nårSendingGet_thenMessageIsReturned () kaster IOException {String url = "// localhost: 8999"; URLConnection-tilkobling = ny URL (url). OpenConnection (); prøv (InputStream respons = connection.getInputStream (); Scanner skanner = ny Scanner (respons)) {String responseBody = scanner.nextLine (); assertEquals ("Velkommen til Baeldung!", responseBody); }}

Som vi kan se, gjør denne metoden ingenting annet enn å sende en GET-forespørsel til webapplikasjonen vi satte opp før og verifisere svaret.

3. Integrasjonstesting i aksjon

En viktig ting å legge merke til om integrasjonstesting er at det tar ofte lang tid å kjøre testmetoder.

Som et resultat, bør vi ekskludere integrasjonstester fra standard livssyklus for bygging, slik at de ikke reduserer hele prosessen hver gang vi bygger et prosjekt.

En praktisk måte å skille integrasjonstester på er å bruke byggeprofiler. Denne typen konfigurasjon lar oss bare utføre integrasjonstester når det er nødvendig - ved å spesifisere en passende profil.

I avsnittene som følger vil vi konfigurere alle integrasjonstester med byggeprofiler.

4. Testing med Failsafe Plugin

Den enkleste måten å kjøre integrasjonstester på er å bruke Maven feilsikker plugg inn.

Som standard er Maven sikker plugin utfører enhetstester under test fase, mens de feilsikker plugin kjører integrasjonstester i integrasjonstest fase.

Vi kan navngi testklasser med forskjellige mønstre for disse pluginene for å plukke de vedlagte testene separat.

Standard navnekonvensjoner håndhevet av sikker og feilsikker er forskjellige, og derfor trenger vi bare å følge disse konvensjonene for å separere enhet- og integrasjonstester.

Utførelsen av sikker plugin inkluderer alle klasser hvis navn starter med Test, eller ender med Test, Tester eller Testforsøk. I kontrast, den feilsikker plugin utfører testmetoder i klasser hvis navn starter med DEN, eller ender med DEN eller ITCase.

Det er her vi kan finne dokumentasjonen angående inkludering av test for sikker, og her er den for feilsikker.

La oss legge til feilsikker plugin til POM med standardkonfigurasjon:

 failsafe maven-failsafe-plugin 2.22.0 integrasjon-test verifisere 

Denne lenken er hvor du finner den nyeste versjonen av feilsikker plugg inn.

Med konfigurasjonen ovenfor vil følgende testmetode bli utført i integrasjonstest fase:

offentlig klasse RestIT {// testmetode vist i underavsnitt 2.3}

Siden Jetty-serveren starter opp i pre-integrasjon-test fase og slås av i post-integrasjon-test, testen vi nettopp har sett passerer med denne kommandoen:

mvn verifisere -Pfailsafe

Vi kan også tilpasse navnemønstrene slik at de inkluderer klasser med forskjellige navn:

 maven-failsafe-plugin 2.22.0 ** / * RestIT ** / RestITCase ... 

5. Testing med Surefire-plugin

Bortsett fra feilsikker plugg inn, vi kan også bruke sikker plugin for å utføre enhet- og integrasjonstester i forskjellige faser.

La oss anta at vi vil nevne alle integrasjonstester med suffikset IntegrationTest. Siden sikker plugin kjører tester med et slikt navn i test fase som standard, må vi ekskludere dem fra standardutførelsen:

 maven-surefire-plugin 2.22.0 ** / * IntegrationTest 

Den siste versjonen av dette pluginet er her.

Vi har tatt alle testklasser som har et navn som slutter med IntegrationTest ut av byggesyklusen. Det er på tide å sette dem tilbake med en profil:

 surefire maven-surefire-plugin 2.22.0 integrasjon-test test ingen ** / * IntegrationTest 

I stedet for å binde test målet for sikker plugin til test bygge fase, som vanlig, bundet vi den til integrasjonstest fase. Plugin vil deretter sparke i løpet av integrasjonstestprosessen.

Legg merke til at vi må sette en utelukke element til ingen for å overstyre ekskluderingen som er angitt i basiskonfigurasjonen.

La oss nå definere en integrasjonstestklasse med vårt navngivningsmønster:

offentlig klasse RestIntegrationTest {// testmetode vist i underavsnitt 2.3}

Denne testen kjører med kommandoen:

mvn verifisere -Psurefire

6. Testing med lasteplugin

Vi kan bruke sikker plugin med Maven last plugg inn. Dette pluginet leveres med innebygd støtte for innebygde servere, som er veldig nyttige for integrasjonstesting.

Flere detaljer om denne kombinasjonen finner du her.

7. Testing med JUnit's @Kategori

En praktisk måte å selektivt utføre tester på er å utnytte @Kategori kommentar i JUnit 4-rammeverket. Denne kommentaren lar oss ekskludere bestemte tester fra enhetstesting, og inkludere dem i integrasjonstesting.

For det første trenger vi et grensesnitt eller klasse for å fungere som en kategoriidentifikator:

pakke com.baeldung.maven.it; Integrasjon av offentlig grensesnitt {}

Vi kan da dekorere en testklasse med @Kategori kommentar og Integrering identifikator:

@Category (Integration.class) offentlig klasse RestJUnitTest {// testmetode vist i underavsnitt 2.3}

Snarere enn å erklære @Kategori kommentar på en testklasse, kan vi også bruke den på metodenivå for å kategorisere individuelle testmetoder.

Ekskluderer en kategori fra test byggefasen er enkel:

 maven-surefire-plugin 2.22.0 com.baeldung.maven.it.Integration 

Inkludert Integrering kategori i integrasjonstest fasen er også grei:

 kategori maven-failsafe-plugin 2.22.0 ** / * com.baeldung.maven.it.Integration integration-test verify 

Vi kan nå kjøre integrasjonstester med en Maven-kommando:

mvn verifisere -Pcategory

8. Legge til en egen katalog for integrasjonstester

Noen ganger er det ønskelig å ha en egen katalog for integrasjonstester. Organisering av tester på denne måten lar oss helt isolere integrasjonstester fra enhetstester.

Vi kan bruke Maven bygge hjelper plugin for dette formålet:

 org.codehaus.mojo build-helper-maven-plugin 3.0.0 add-integration-test-source generere-test-kilder add-test-source src / integration-test / java 

Her er hvor vi kan finne den nyeste versjonen av dette pluginet.

Konfigurasjonen vi nettopp har sett, legger til en testkildekatalog til bygningen. La oss legge til en klassedefinisjon i den nye katalogen:

offentlig klasse RestITCase {// testmetode vist i underavsnitt 2.3}

Det er på tide å kjøre integrasjonstester i denne klassen:

mvn verifisere -Pfailsafe

The Maven feilsikker plugin vil utføre metoder i denne testklassen på grunn av konfigurasjonen vi angir i underavsnitt 3.1.

En testkildekatalog følger ofte med en ressurskatalog. Vi kan legge til en slik katalog i en annen henrettelse element til plugin-konfigurasjonen:

 ... add-integration-test-resource generere-test-resources add-test-resource src / integration-test / resources 

9. Konklusjon

Denne artikkelen gikk over å bruke Maven til å kjøre integrasjonstester med en Jetty-server, med fokus på konfigurasjonen av Maven sikker og feilsikker plugins.

Den komplette kildekoden for denne opplæringen finner du på GitHub.


$config[zx-auto] not found$config[zx-overlay] not found