Java >> Java tutorial >  >> Tag >> maven

Integrationstest med Maven Cargo plugin

1. Oversigt

Et meget almindeligt behov i et projekts livscyklus er at opsætte integrationstest. I denne vejledning vil vi se, hvordan du opsætter dette scenarie ved hjælp af Maven Cargo-plugin'et.

2. Maven Integration Test Bygningsfaser

Heldigvis har Maven indbygget understøttelse af dette nøjagtige scenarie med følgende faser af standardbyggets livscyklus (fra Maven-dokumentationen):

  • præ-integrationstest :Udfør nødvendige handlinger, før integrationstest udføres. Dette kan involvere ting som f.eks. at opsætte det nødvendige miljø.
  • integrationstest :Behandle og implementer pakken om nødvendigt i et miljø, hvor integrationstest kan køres.
  • post-integration-test :Udfør de nødvendige handlinger, efter at integrationstest er blevet udført. Dette kan omfatte oprydning i miljøet.

3. Konfigurer Cargo Plugin

Lad os gennemgå den nødvendige opsætning trin for trin.

3.1. Ekskluder integrationstest fra Surefire-plugin'et

For det første er maven-surefire-plugin'et konfigureret, så integrationstests er udelukket fra standard build-livscyklussen:

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-plugin</artifactId>
   <version>2.22.2</version>
   <configuration>
      <excludes>
         <exclude>**/*IntegrationTest.java</exclude>
      </excludes>
   </configuration>
</plugin>

Ekskluderinger udføres via sti-udtryk i myrestil, så alle integrationstest skal følge dette mønster og slutte med “IntegrationTest.java “.

3.2. Konfigurer Cargo Plugin

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

<plugin>
   <groupId>org.codehaus.cargo</groupId>
   <artifactId>cargo-maven3-plugin</artifactId>
   <version>1.9.9</version>
   <configuration>
      <configuration>
         <properties>
            <cargo.servlet.port>8080</cargo.servlet.port>
         </properties>
      </configuration>
   </configuration>
</plugin>

En standard integreret Jetty 9-webserver er defineret, som lytter på port 8080.

I den nyere version af fragt (1.1.0 opefter) er standardværdien for den vent flag er blevet ændret til false, til cargo:start . Dette mål bør kun bruges til at køre integrationstest og er bundet til Mavens livscyklus; til udvikling, cargo:run målet skal udføres i stedet – som har wait=true .

For at få pakken maven fase for at generere en deployerbar krig fil, skal emballagen af ​​projektet være war .

3.3. Tilføj en ny Maven-profil

Dernæst en ny integration Maven-profil er oprettet for kun at aktivere integrationstesten når denne profil er aktiv og ikke som en del af standard build-livscyklussen.

<profiles>
   <profile>
      <id>integration</id>
      <build>

         <plugins>
            ...
         </plugins>

      </build>
   </profile>
</profiles>

Det er denne profil, der vil indeholde alle de resterende konfigurationsdetaljer.

Nu er Jetty-serveren konfigureret til at starte i præ-integrationstesten fase og stop i post-integration-testen fase.

<plugin>
   <groupId>org.codehaus.cargo</groupId>
   <artifactId>cargo-maven3-plugin</artifactId>
   <executions>
      <execution>
         <id>start-server</id>
         <phase>pre-integration-test</phase>
         <goals>
            <goal>start</goal>
         </goals>
      </execution>
      <execution>
         <id>stop-server</id>
         <phase>post-integration-test</phase>
         <goals>
            <goal>stop</goal>
         </goals>
      </execution>
   </executions>
</plugin>

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

3.4. Konfigurer integrationstest i den nye profil

Dernæst maven-surefire-plugin konfigurationen skal tilsidesættes inde i integrationen profil, så de integrationstest, der blev udelukket i standardlivscyklussen, nu bliver inkluderet og kør:

<plugins>
   <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <executions>
         <execution>
            <phase>integration-test</phase>
            <goals>
               <goal>test</goal>
            </goals>
            <configuration>
               <excludes>
                  <exclude>none</exclude>
               </excludes>
               <includes>
                  <include>**/*IntegrationTest.java</include>
               </includes>
            </configuration>
         </execution>
      </executions>
   </plugin>
</plugins>

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

1. testen mål for maven-surefire-plugin udføres i integrationstesten fase; på dette tidspunkt er Jetty allerede startet med projektet implementeret, så integrationstesten burde køre uden problemer.

2. Integrationstestene er nu inkluderet i udførelsen. For at opnå dette tilsidesættes udelukkelserne også – dette er på grund af den måde Maven håndterer tilsidesættende plugin-konfigurationer inde i profiler.

Basiskonfigurationen er ikke fuldstændig tilsidesat, men snarere udvidet med nye konfigurationselementer inde i profilen.

På grund af dette, konfiguration, som udelukkede integrationstestene i første omgang, er stadig til stede i profilen og skal tilsidesættes, ellers ville den være i konflikt med konfiguration og testene ville stadig ikke køre.

3. Bemærk det, da der kun er en enkelt element, er der intet behov for et id skal defineres.

Nu kan hele processen køre:

mvn clean install -Pintegration

4. Konklusion

Trin-for-trin-konfigurationen af ​​Maven dækker hele processen med at opsætte integrationsprocessen som en del af projektets livscyklus.

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

For en fuldt kørende konfiguration af denne mekanisme, tjek REST GitHub-projektet ud.

Tjek også denne artikel for bedste praksis for at strukturere et projekt og organisere enheds- og integrationstests.


Java tag