streamalism.org

1. Oversigt

Maven er det mest populære byggeværktøj i Java-rummet, mens integrationstest er en vigtig del af udviklingsprocessen. Derfor, det er et naturligt valg at konfigurere og udføre integrationstest med Maven.

I denne vejledning gennemgår vi en række forskellige måder at bruge Maven til integrationstest og at adskille integrationstest fra enhedstest.

2. Forberedelse

For at gøre demonstrationskoden tæt på et virkeligt projekt opretter vi en JAX-RS-applikation. Denne applikation distribueres til en server inden udførelse af integrationstest og demonteres bagefter.

2.1. Maven-konfiguration

Vi bygger vores REST-applikation omkring Jersey - referenceimplementeringen af ​​JAX-RS. Denne implementering kræver et par afhængigheder:

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

Vi kan finde de nyeste versioner af disse afhængigheder her og her.

Vi bruger Jetty Maven-pluginet til at oprette et testmiljø. Dette plugin starter en Jetty-server under præ-integration-test fase af Maven bygge livscyklus, derefter stopper den i post-integration-test fase.

Sådan konfigurerer vi Jetty Maven-pluginet pom.xml:

 org.eclipse.jetty jetty-maven-plugin 9.4.11.v20180605 8999 afslut 9000 start-anløbsbro før integration-test start stop-anløbsbro efter integration-test stop 

Når Jetty-serveren starter, lytter den til havn 8999. Det stopKey og stopPort konfigurationselementer bruges udelukkende af plugins hold op mål og deres værdi er ikke vigtigt i vores perspektiv.

Her finder du den nyeste version af Jetty Maven-pluginet.

En anden ting at bemærke er, at vi skal indstille emballage element i pom.xml fil til krig, ellers kan Jetty-pluginet ikke starte serveren:

krig

2.2. Oprettelse af en REST-applikation

Applikationens slutpunkt er meget simpelt - at returnere en velkomstmeddelelse, når en GET-anmodning rammer kontekstens rod:

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

Sådan registrerer vi slutpunktsklassen hos Jersey:

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

For at have Jetty-serveren opmærksom på vores REST-applikation kan vi bruge en klassiker web.xml implementeringsbeskrivelse:

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

Denne deskriptor skal placeres i biblioteket / src / main / webapp/ WEB-INF at blive genkendt af serveren.

2.3. Testkode på klientsiden

Alle testklasser i de følgende sektioner indeholder en enkelt metode:

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

Som vi kan se, gør denne metode intet andet end at sende en GET-anmodning til den webapplikation, vi oprettede før, og bekræfte svaret.

3. Integrationstest i aktion

En vigtig ting at bemærke om integrationstest er, at Det tager ofte lang tid at køre testmetoder.

Som et resultat bør vi udelukke integrationstests fra standardbygningens livscyklus og forhindre dem i at bremse hele processen hver gang vi bygger et projekt.

En praktisk måde at adskille integrationstests på er at bruge buildprofiler. Denne form for konfiguration giver os kun mulighed for at udføre integrationstest, når det er nødvendigt - ved at angive en passende profil.

I de følgende afsnit konfigurerer vi alle integrationstest med buildprofiler.

4. Test med fejlsikker plugin

Den enkleste måde at køre integrationstest på er at bruge Maven fejlsikker plugin.

Som standard er Maven sikkert plugin udfører enhedstest under prøve fase, mens det fejlsikker plugin kører integrationstest i integration-test fase.

Vi kan navngive testklasser med forskellige mønstre for disse plugins for at hente de vedlagte tests separat.

Standard navngivningskonventioner håndhævet af sikkert og fejlsikker er forskellige, og derfor er vi bare nødt til at følge disse konventioner for at adskille test af enheder og integration.

Udførelsen af sikkert plugin inkluderer alle klasser, hvis navn starter med Prøveeller slutter med Prøve, Test eller Test sag. I modsætning hertil er fejlsikker plugin udfører testmetoder i klasser, hvis navn starter med DETeller slutter med DET eller ITCase.

Det er her, vi kan finde dokumentationen vedrørende testinddragelse til sikkert, og her er den ene til fejlsikker.

Lad os tilføje fejlsikker plugin til POM med standardkonfiguration:

 failsafe maven-failsafe-plugin 2.22.0 integration-test verificer 

Dette link er, hvor du finder den nyeste version af fejlsikker plugin.

Med ovenstående konfiguration udføres følgende testmetode i integration-test fase:

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

Da Jetty-serveren starter i præ-integration-test fase og lukker ned i post-integration-test, den test, vi lige har set, passerer med denne kommando:

mvn verificere -Pfailsafe

Vi kan også tilpasse navngivningsmønstrene, så de inkluderer klasser med forskellige navne:

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

5. Test med Surefire Plugin

Bortset fra fejlsikker plugin, vi kan også bruge sikkert plugin til at udføre enheds- og integrationstest i forskellige faser.

Lad os antage, at vi vil navngive alle integrationstest med suffikset IntegrationTest. Siden den sikkert plugin kører tests med et sådant navn i prøve fase som standard skal vi udelukke dem fra standardudførelsen:

 maven-surefire-plugin 2.22.0 ** / * IntegrationTest 

Den seneste version af dette plugin er her.

Vi har taget alle testklasser, der har et navn, der slutter med IntegrationTest ud af bygningens livscyklus. Det er tid til at sætte dem tilbage med en profil:

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

I stedet for at binde prøve målet for sikkert plugin til prøve bygge fase, som normalt, bundet vi det til integration-test fase. Pluginet begynder derefter i løbet af integrationstestprocessen.

Bemærk, at vi skal indstille en udelukke element til ingen for at tilsidesætte den eksklusion, der er angivet i basiskonfigurationen.

Lad os nu definere en integrationstestklasse med vores navngivningsmønster:

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

Denne test kører med kommandoen:

mvn verificere -Psurefire

6. Test med ladeplugin

Vi kan bruge sikkert plugin med Maven last plugin. Dette plugin leveres med indbygget support til indlejrede servere, som er meget nyttige til integrationstest.

Flere detaljer om denne kombination kan findes her.

7. Test med JUnit's @Kategori

En praktisk måde at udføre test selektivt på er at udnytte @Kategori kommentar i JUnit 4-rammen. Denne kommentar giver os mulighed for at udelukke bestemte tests fra enhedstest og inkludere dem i integrationstest.

For det første har vi brug for en grænseflade eller klasse for at fungere som en kategori-id:

pakke com.baeldung.maven.it; integration af offentlige grænseflader {}

Vi kan derefter dekorere en testklasse med @Kategori kommentar og Integration identifikator:

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

I stedet for at erklære @Kategori kommentar på en testklasse, vi kan også bruge den på metodeniveau til at kategorisere individuelle testmetoder.

Ekskluderer en kategori fra prøve byggefasen er enkel:

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

Herunder Integration kategori i integration-test fase er også ligetil:

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

Vi kan nu køre integrationstest med en Maven-kommando:

mvn verificere -Pcategory

8. Tilføjelse af et separat katalog til integrationstests

Det er til tider ønskeligt at have en separat mappe til integrationstests. Organisering af tests på denne måde giver os mulighed for fuldstændigt at isolere integrationstest fra enhedstest.

Vi kan bruge Maven bygge hjælper plugin til dette formål:

 org.codehaus.mojo build-helper-maven-plugin 3.0.0 tilføj-integration-test-kilde generer-test-kilder tilføj-test-kilde src / integration-test / java 

Her kan vi finde den nyeste version af dette plugin.

Den konfiguration, vi lige har set, tilføjer en testkildekatalog til bygningen. Lad os tilføje en klassedefinition til den nye mappe:

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

Det er tid til at køre integrationstest i denne klasse:

mvn verificere -Pfailsafe

Maven fejlsikker plugin udfører metoder i denne testklasse på grund af den konfiguration, vi indstiller i underafsnit 3.1.

En testkildekatalog følger ofte med en ressourcekatalog. Vi kan tilføje en sådan mappe i en anden udførelse element til plugin-konfigurationen:

 ... tilføj-integration-test-ressource generer-test-ressourcer tilføj-test-ressource src / integration-test / ressourcer 

9. Konklusion

Denne artikel gik over at bruge Maven til at køre integrationstest med en Jetty-server med fokus på konfigurationen af ​​Maven sikkert og fejlsikker plugins.

Den komplette kildekode til denne vejledning kan findes på GitHub.