streamalism.org

Et veldig vanlig behov i livssyklusen til et prosjekt er å sette opp integrasjonstesting. Heldigvis har Maven innebygd støtte for akkurat dette scenariet, med følgende faser i standard byggesyklus (fra Maven-dokumentasjonen):

• pre-integrasjon-test: Utfør nødvendige handlinger før integrasjonstester utføres. Dette kan innebære ting som å sette opp det nødvendige miljøet.
• integrasjonstest: Behandle og distribuere pakken om nødvendig i et miljø der integrasjonstester kan kjøres.
• post-integrasjon-test: Utfør nødvendige handlinger etter at integrasjonstester er utført. Dette kan inkludere rydding i miljøet.

Først er maven-surefire-plugin konfigurert slik at integrasjonstester er ekskludert fra standard byggesyklus:

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

Ekskluderinger gjøres via ant-stil stiuttrykk, så alle integrasjonstester må følge dette mønsteret og ende med “IntegrationTest.java“.

Neste, den last-maven2-plugin brukes, ettersom Cargo kommer med førsteklasses støtte for innebygde webservere. Selvfølgelig, hvis servermiljøet krever spesifikk konfigurasjon, vet last også hvordan man skal konstruere serveren av en arkivert pakke samt distribuere til en ekstern server.

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

Det er definert en innebygd Jetty 8-webserver som lytter på port 8080.

I nyere versjon av last (1.1.0 og oppover) er standardverdien på de vente flagg er endret til falsk, til last: start. Dette målet skal bare brukes til å kjøre integrasjonstester og er bundet til Maven livssyklus; for utvikling, den last: kjør mål skal utføres i stedet - som har vent = sant.

For at pakke maven fase for å generere en kan distribueres krig filen, må emballasjen til prosjektet være: krig.

Neste, en ny integreringMaven profil er opprettet for å muliggjøre kjøring av integrasjonstestene kun når denne profilen er aktiv, og ikke som en del av standard byggesyklus.

  integrering ... 

Det er denne profilen som inneholder alle gjenværende konfigurasjoner.

Nå er Jetty-serveren konfigurert til start i pre-integrasjon-test fase og Stoppe i post-integrasjon-test fase.

 org.codehaus.cargo cargo-maven2-plugin falsk start-server pre-integrasjon-test start stopp-server post-integrasjon-test stopp 

Dette sikrer at last: start mål og last: stopp mål vil utføres før og etter integrasjonstest fase. Merk at fordi det er to individuelle henrettelse definisjoner, den id elementet må være til stede (og annerledes) i begge, slik at Maven kan godta konfigurasjonen.

Neste, maven-surefire-plugin konfigurasjonen må overstyres inne i integrering profil, slik at integrasjonstestene som ble ekskludert i standard livssyklus er nå inkludert og løp:

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

Det er noen få ting som er verdt å merke seg:

1. test målet for maven-surefire-plugin blir henrettet i integrasjonstest fase; på dette tidspunktet er Jetty allerede startet med prosjektet distribuert, så integrasjonstestene skal kjøre uten problemer.

2. Integrasjonstestene er nå inkludert i henrettelsen. For å oppnå dette overstyres også unntakene - dette er fordi Maven håndterer overordnede plugin-konfigurasjoner i profiler. Basekonfigurasjonen er ikke fullstendig tilsidesatt, men forsterket med nye konfigurasjonselementer inne i profilen. På grunn av dette, originalen konfigurasjon, som i utgangspunktet ekskluderte integrasjonstestene, er fremdeles tilstede i profilen og må overstyres, ellers vil den komme i konflikt med konfigurasjonen og testene vil fortsatt ikke kjøre.

3. Merk at siden det bare er en singel element, det er ikke behov for en id skal defineres.

Nå kan hele prosessen kjøre:

mvn ren installasjon -Integrasjon

Konklusjon

Den trinnvise konfigurasjonen av Maven dekker hele prosessen med å sette opp integrasjonsprosessen som en del av prosjektets livssyklus.

Vanligvis er dette satt opp for å kjøre i et kontinuerlig integrasjonsmiljø, helst etter hver forpliktelse. Hvis CI-serveren allerede har en server som kjører og forbruker porter, må lastkonfigurasjonen håndtere det scenariet, som jeg vil dekke i et fremtidig innlegg.

For en fullstendig konfigurasjon av denne mekanismen, sjekk ut REST GitHub-prosjektet.

Sjekk også ut denne artikkelen for beste praksis for strukturering av et prosjekt og organisering av enhet- og integrasjonstester.