Maven beroende och integration med förmörkelse och testNG

maven dependency integration with eclipse

I denna handledning kommer vi att diskutera integrationen av Maven med Eclipse och TestNG, Maven Dependency Scope och Maven Deployment Automation i detalj:

I föregående handledning diskuterade vi jämförelsen mellan Gradle vs Maven och Maven Plugins. Denna handledning förklarar hur man integrerar Maven med andra verktyg, Maven-beroende och Maven-distribution.

öppna .bin-filfönster 10

Låt oss börja!

=> Besök här för den exklusiva Maven Training Tutorial Series.

Vad du kommer att lära dig:

• Integration av Maven med Eclipse
• Integration av Maven med TestNG
• Maven Beroende Omfattning
  • # 1) Runtime Scope
  • # 2) Systemomfattning
  • # 3) Tillhandahållet omfattning
  • # 4) Testomfång
  • # 5) Importera omfattning
  • # 6) Kompilera omfattning
• Maven Deployment Automation
• Maven Release Plugin
• Slutsats
• Rekommenderad läsning

Integration av Maven med Eclipse

Hur man integrerar Maven med Eclipse har redan diskuterats ingående om detta sida

I vissa scenarier där vi bygger ett Maven-projekt från kommandotolken och vi måste ta det projektet till Eclipse, ska följande steg utföras.

# 1) Navigera till platsen för pom-filen för Maven-projektet. Kör kommandot nedan.

mvn-förmörkelse: förmörkelse

# 2). Klassväg och .projekt kommer att skapas på platsen för Maven-projektet.

Kontrollera om Maven-plugin redan finns i Eclipse från Windows => Inställningar , Maven borde vara där. Alla nuvarande Eclipse-versioner har Maven-plugins som standard och om det inte finns där kan vi hämta det från här .

# 3) För att få Maven och Eclipse att fungera tillsammans, importera Maven-projektet från filen. Välj sedan Befintligt Maven-projekt.

# 4) Bläddra bland projektets plats och fortsätt.

Bilden som visas ovan visar Maven-projektet importerat till Eclipse.

Integration av Maven med TestNG

Hur man integrerar Maven med TestNG har diskuterats ingående på nedanstående sida.

=> Integration av Maven med TestNg med hjälp av Maven Surefire Plugin

Även om vi har integrerat Maven med TestNG i vårt projekt kan det finnas situationer där vårt projekt har mer än en Testng xml-fil. Till exempel, Hela regressionsfunktionerna beskrivs i en testng.xml och sanity testfall beskrivs i den andra testng.xml-filen.

I en sådan situation måste vi använda profil koncept i Maven. I pom-filen måste vi definiera profilerna. Var och en är en del av taggen och har en koppling till den.

En pom.xml-fil med profilkodavsnitt ges nedan:

Observera att vi har två profiler ovan, beskrivna under och varje profil har ett id associerat med sig. Till exempel, Regression och Förnuft också, under suiteXmlFiles, definierade vi namnet på Testng xml-filen som motsvarar id ( testngRegression.xml och testngSanity.xml ).

hur man öppnar .key-filen i Windows 10

Således har vi två profiler här och vi kan styra varje Testng-fil med hjälp av en enda pom-fil.

För att utlösa ett testfall för varje Testng-fil direkt från kommandotolken måste vi flytta till projektmappen och köra följande kommando.

När detta har körts söker Maven i profilen med id-regression och motsvarande testngRegression.xml fil. Således utförs bara de tester som är involverade där.

På samma sätt är kommandot för en profil med id Sanity:

Här är testngSanity.xml filen används för att bestämma de testfall som ska köras. Således för att utlösa en viss uppsättning testfall behöver vi inte ändra TestNG-filnamnet i pom, utan det kan enkelt uppnås genom att underhålla separata TestNG-filer.

I pom-filen kan vi mappa dessa filer och slutligen köra dem med hjälp av profiler i Maven från kommandotolken.

Maven Beroende Omfattning

Maven har totalt sex omfattningar enligt nedan.

• Försedd
• Testa
• Systemet
• Importera
• Sammanställa
• Körning

# 1) Runtime Scope

Maven-beroende har ett omfång som körtid och används inte för byggändamål. Det utgör en klassväg för att köra och testa projektet. Kodavsnittet nedan visar ett beroende av runtime.

# 2) Systemomfattning

Maven-beroende med omfattning som system liknar det angivna omfånget. Systemberoenden kan inte laddas ner från fjärrförvaret och finns vanligtvis i projektets kataloger. Nedanstående kodavsnitt visar beroendet av systemomfånget.

# 3) Tillhandahållet omfattning

Maven-beroende som har en omfattning som anges krävs för att bygga och testa projekten. Det rekommenderas inte att exportera detta beroende eftersom de är tillgängliga under körningstiden. Detta beroende krävs dock för att köra build. Nedanstående kodavsnitt visar ett angivet omfångsberoende.

# 4) Testomfång

Mavenberoende som har testets omfattning krävs inte för att bygga och driva projektet. De används huvudsakligen för att sammanställa och köra enhetstestfall. Nedanstående kodavsnitt visar beroendet av testomfång.

# 5) Importera omfattning

Inuti pom-filen är dependencyManagement avsnittet omfattar import. Detta betyder att beroendet ska ändras med den effektiva gruppen beroenden som tillhandahålls i avsnittet dependencyManagement i pom-filen. Kodavsnittet nedan visar ett beroende av importomfång.

# 6) Kompilera omfattning

Maven-beroende som har kompileringsomfång är standard. Detta beroende är viktigt för att bygga, testa och driva projektet. Detta är mest viktigt för att lösa Java-källkod med importuttalanden. Nedanstående kodavsnitt visar kompileringsomfattningsberoende.

Maven Deployment Automation

Projektdistribution är en kritisk fas och involverar flera steg definierade enligt nedan:

1. Koden som utvecklats för att kontrolleras i förvaret.
2. Källkod som ska laddas ner från förvaret.
3. Sammanställning och byggande av applikationen och generering av JAR- eller WAR-filer.
4. Att placera de identifierade JAR- eller WAR-filerna på en bekant nätverksplats.
5. Ladda JAR- eller WAR-filerna.
6. Distribuera de nedladdade JAR- eller WAR-filerna till målservern.
7. Det nya versionsnumret på applikationen och det datum som ska uppdateras i dokumentationen.

Ovan nämnda steg följs av varje medlem av de team som är inblandade i projektet. Av de ovan nämnda stegen, om någon saknas eller något inte görs ordentligt, så resulterar det i misslyckande med byggande och distribution . Så däremellan, om det finns några fel, måste de åtgärdas automatiskt.

Maven följer distributionsautomatiseringsmetoden för att göra distributionen automatisk och robust. Detta uppnås genom kombinationen av de processer som anges nedan:

• Bygga och släppa projektet som ska tas om hand av Maven.
• Källkod som ska hanteras av subversion och källkodsförvar.
• Projekt binärer för att ta hand om fjärrlagringshanteraren.

Mavens automatiska bygg- och släppprocess sköts av plugin-programmet Maven Release. Pom.xml-filen bör uppdateras enligt bilden nedan.

Koden nedan är för com.softwaretestHelp-projektet pom.xml

De framträdande funktionerna i ovanstående pom.xml-fil listas nedan:

• SCM : Platsen för SVN (där källkoden finns) konfigureras av SCM.
• Förvar : Detta är platsen för JAR- eller WAR- eller EAR-filer eller någon annan projektartefakt efter att projektet har slutförts.
• Plug-in : Distributionsautomatisering utförd av Maven release plugin.

Maven Release Plugin

Maven release-plugin utför följande aktiviteter:

• mvn-frigöring: rengör - Det rensar arbetsytan för den tidigare byggnaden innan ankomsten av den framtida byggnaden.
• mvn release: återställning - I händelse av att den tidigare versionen misslyckades, återställs den till arbetsytan.
• mvn release: förbered - Det verifierar om det finns några obundna ändringar i filer eller inte. Kontrollerar också beroendet av ögonblicksbilden och uppdaterar applikationsversionsnumret. Det ändrar pom till SCM. Det tar hand om utförandet av testfallet och förbinder den slutliga koden SCM. Det utför märkning av koden i subversionen. Slutligen ökas versionsnumret och bifogas SNAPSHOT för andra utgåvor i framtiden av detta plugin.
• mvn release: utför - Den kontrollerar koden som finns i förvaret och kör sedan Maven build-mål för att distribuera byggartefakten till förvaret.

Slutligen måste vi köra kommandot nedan för att bygga projektet:

När den lyckade slutförandet av byggnaden är klar kör du följande kommando:

Nu överförs WAR-filen till förvaret.

Slutsats

Vi hoppas att större delar av Maven-integrationen med Eclipse, dess integration med TestNG, Maven-profiler, beroendeförhållandet för Maven och distributionsautomatisering av Maven bör vara förståelig nu. Vi har också diskuterat de flesta av beroendets omfattningar här.

För Maven-implementeringsprocessen utforskade vi alla steg på djupet och förklarade några av Maven-release-plugins. Läs igenom ämnena och så småningom kommer du att förstå den verkliga essensen av att använda Maven i vårt arbete.

html5 intervjufrågor och svar för erfarna

Vi fortsätter med serien och samlar kunskap om Maven Jenkins Integration, Maven intervjufrågor osv i våra kommande handledning.

=> Kontrollera ALLA Maven-handledning här.

Rekommenderad läsning

• Vad är Maven - Maven-handledning för nybörjare
• Fördjupade förklaringar om förmörkelser för nybörjare
• TestNG Tutorial: Introduktion till TestNG Framework
• Eclipse Tutorial: Integrera TestNG i Eclipse Java IDE
• Konfigurera Maven med Eclipse Java IDE
• Gradle Vs Maven And Maven Plugins
• Maven With Jenkins & Maven Documentation For Projects
• Integration av Maven med TestNg med hjälp av Maven Surefire Plugin