Integrationstest med Maven Cargo-pluginet

Et meget almindeligt behov i et projekts livscyklus er opsætning af integrationstest. Heldigvis har Maven indbygget understøttelse af dette nøjagtige scenarie med følgende faser af standardbygningens livscyklus (fra Maven-dokumentationen):

  • præ-integration-test: Udfør de nødvendige handlinger, før integrationstests udføres. Dette kan involvere ting som f.eks. Opsætning af det krævede miljø.
  • integration-test: Behandl og implementer pakken om nødvendigt i et miljø, hvor integrationstests kan køres.
  • post-integration-test: Udfør de nødvendige handlinger, efter at integrationstests er udført. Dette kan omfatte oprydning af miljøet.

For det første er maven-surefire-plugin konfigureret således integrationstest er ekskluderet fra standardbygningens livscyklus:

 org.apache.maven.plugins maven-surefire-plugin 2.17 ** / * IntegrationTest.java 

Eksklusioner udføres via stiudtryk i ant-stil, så alle integrationstest skal følge dette mønster og slutte med “IntegrationTest.java“.

Dernæst cargo-maven2-plugin bruges, da Cargo leveres med top-notch out of the box support til indlejrede webservere. Selvfølgelig, hvis servermiljøet kræver specifik konfiguration, ved last også, hvordan man konstruerer serveren ud af en arkiveret pakke såvel som distribueres til en ekstern server.

 org.codehaus.cargo cargo-maven2-plugin 1.4.8 jetty8x integreret 8080 

En integreret Jetty 8-webserver er defineret, der lytter på port 8080.

I nyere version af fragt (1.1.0 opad) er standardværdien på det vente flag er blevet ændret til falsk, til fragt: start. Dette mål skal kun bruges til at køre integrationstest og er bundet til Maven livscyklus; til udvikling, last: kør mål skal udføres i stedet - hvilket har Vent = sandt.

For at pakke maven fase for at generere en kan implementeres krig fil skal projektets emballage være: krig.

Dernæst en ny integrationMaven profil er oprettet for at aktivere kørsel af integrationstest kun når denne profil er aktiv, og ikke som en del af standardbygningens livscyklus.

  integration ... 

Det er denne profil, der indeholder alle de resterende konfigurationer.

Nu er Jetty-serveren konfigureret til Start i præ-integration-test fase og hold op i post-integration-test fase.

 org.codehaus.cargo cargo-maven2-plugin falsk start-server pre-integration-test start stop-server post-integration-test stop 

Dette sikrer, at fragt: start mål og fragt: stop mål udføres før og efter integration-test fase. Bemærk, at der er to individuelle udførelse definitioner, den id elementet skal være til stede (og forskelligt) i begge, så Maven kan acceptere konfigurationen.

Næste, maven-surefire-plugin konfiguration skal tilsidesættes inden i integration profil, så de integrationstest, der blev ekskluderet i standardlivscyklussen, er vil nu inkluderet og løb:

  org.apache.maven.plugins maven-surefire-plugin integration-test test ingen ** / * IntegrationTest.java 

Der er et par ting, der er værd at bemærke:

1. Den prøve målet for maven-surefire-plugin udføres i integration-test fase; på dette tidspunkt er Jetty allerede startet med det implementerede projekt, så integrationstestene skal køre uden problemer.

2. Integrationstestene er nu inkluderet i udførelsen. For at opnå dette tilsidesættes udelukkelserne også - det er fordi Maven håndterer overordnede plugin-konfigurationer inde i profiler. Grundkonfigurationen tilsidesættes ikke fuldstændigt, men forstærkes snarere med nye konfigurationselementer inde i profilen. På grund af dette, originalen konfiguration, der i første omgang ekskluderede integrationstestene, er stadig til stede i profilen og skal tilsidesættes, ellers ville den være i konflikt med konfiguration, og testene kører stadig ikke.

3. Bemærk, at da der kun er en enkelt element, der er intet behov for en id at blive defineret.

Nu kan hele processen køre:

mvn ren installation -Pintegration

Konklusion

Trin for trin-konfiguration af Maven dækker hele processen med at konfigurere integrationsprocessen som en del af projektets livscyklus.

Normalt er dette indstillet til at køre i et kontinuerligt integrationsmiljø, helst efter hver forpligtelse. Hvis CI-serveren allerede har en server, der kører og forbruger porte, skal lastkonfigurationen håndtere det scenario, som jeg vil dække i et fremtidigt indlæg.

For en fuldt kørende konfiguration af denne mekanisme skal du tjekke ud REST GitHub-projektet.

Tjek også denne artikel for bedste praksis for strukturering af et projekt og organisering af enheds- og integrationstest.


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