Come integrare Jenkins e Maven con Selenium?
Il Settembre 23, 2021 da adminQuesto articolo fa parte del nostro Content Hub. Per risorse più approfondite, controlla il nostro content hub su Jenkins Tutorial.
Jenkins è uno degli strumenti popolari per l’integrazione continua, la gestione della build e i test di automazione. Maven è un popolare strumento di automazione della compilazione che è ampiamente utilizzato per i progetti Java. La combinazione di Selenium, Maven, integrazione Jenkins è l’apice dell’integrazione e della distribuzione continua.
Come parte dei test di automazione, siamo sicuri che il tuo team si presenta con numerosi script di automazione di test Selenium ogni due giorni. Poiché Selenium stesso non è usato per l’integrazione continua, Selenium, Maven e l’integrazione Jenkins sono utilizzati per la gestione della build e l’integrazione continua. In questo articolo, vediamo l’uso di Maven e Jenkins con Selenium.
Un rapido riassunto del post sul blog è qui sotto:
Overview Of Selenium, Maven, & Jenkins
Maven è un popolare strumento di build automation che viene usato principalmente per progetti Java. Il vantaggio di usare Maven è che le librerie e i plugin Java sono scaricati su base dinamica dal Maven 2 Central Repository.
Le dipendenze e altre informazioni essenziali relative alla compilazione sono memorizzate in un file pom.xml del progetto. Una volta scaricate, le dipendenze sono memorizzate in una cache locale (.M2 repository), e la stessa è usata per la generazione della build. Questo semplifica il processo di compilazione, poiché ogni nuova dipendenza del progetto deve essere aggiunta solo in pom.xml, cioè, non sono richiesti pacchetti di download e installazione manuali.
Selenium è un framework di automazione dei test ampiamente utilizzato per la validazione delle applicazioni web attraverso diverse combinazioni di browser, piattaforme e dispositivi (o emulatori). Potete fare riferimento ai nostri blog su come Selenium Grid può essere usato per i test automatizzati del browser.
Jenkins è uno strumento CI/CD open-source che aiuta nell’automazione delle attività relative alla compilazione, ai test e alla distribuzione. Jenkins ha un vasto ecosistema di plugin, è open-source e una comunità appassionata – fattori che possono essere attribuiti alle caratteristiche di Jenkins.
In questo blog Maven e Jenkins con Selenium, useremo TestNG, che è un popolare framework di test ispirato a JUnit. È ampiamente utilizzato per aree di test come i test funzionali, i test end-to-end e altro ancora.
Questo è l’insieme di strumenti che useremo nella dimostrazione:
- Maven – Strumento di gestione dei progetti in Java
- TestNG – Popolare framework di automazione dei test
- Selenium WebDriver – Libreria usata principalmente per l’automazione delle interazioni del browser
- Jenkins – Strumento di integrazione continua (CI) e distribuzione continua (CD)
Ecco il flusso generale di informazioni quando Selenium, Maven e Jenkins sono integrati:
- Una volta che lo sviluppatore spinge il codice nel repository (es.g., GitHub), viene attivata una compilazione Jenkins.
- Maven scarica i pacchetti delle librerie dipendenti & e inizia ad eseguire la compilazione. Le informazioni relative alla suite di test sono disponibili in testing.xml, e le stesse vengono utilizzate anche in
pom.xml
. - Si imposta un obiettivo di build (ad esempio, installare) per l’esecuzione dei test automatici. Lo stesso si ottiene attraverso il maven-surefire-plugin.
- Il maven-surefire-plugin dice a TestNG di eseguire i test che sono sotto l’annotazione @Test.
- A seconda dell’AUT (applicazione sotto test) e del browser (& combinazione OS) su cui vengono eseguiti i test cross browser, il Selenium WebDriver invoca l’istanza del browser corrispondente ed esegue gli stessi test di automazione.
- I risultati dei test vengono pubblicati in HTML Reports, poiché il plugin HTML Publisher viene utilizzato per la generazione dei report.
- Anche se un singolo caso di test è fallito, il test completo è contrassegnato dallo stato ‘Failed.
Advantages Of Using Maven & Jenkins With Selenium
Prima di dimostrare l’uso dell’integrazione Selenium Maven Jenkins, daremo uno sguardo ai principali vantaggi dell’uso di Maven e Jenkins con Selenium:
- Ogni volta che viene fatto un cambiamento nell’implementazione, le modifiche vengono distribuite nell’ambiente di test. I test di automazione vengono eseguiti continuamente, e gli sviluppatori sono tenuti informati sui risultati della compilazione e della fase di test.
- Le suite di test che comprendono molti scenari di test (o combinazioni di test) potrebbero richiedere una durata maggiore per i test di automazione. In questi casi può essere programmata una compilazione notturna per la compilazione e l’esecuzione sul server Jenkins.
- Come Maven usa pom.xml, riduce la dipendenza complessiva del download manuale dei file jar. Inoltre, il tipo ‘Maven Project’ in Jenkins aiuta a iniziare con Selenium Maven, l’integrazione di Jenkins con poche impostazioni di configurazione.
- Il setup di integrazione Selenium Maven Jenkins è adatto a team di sviluppo e test distribuiti in diverse località geografiche.
Prequisiti per il progetto Jenkins Selenium
Per la dimostrazione di Maven e Jenkins con Selenium, i seguenti software dovrebbero essere installati (o disponibili) sulla macchina da cui vengono lanciati i test:
- Eclipse IDE o IntelliJ IDEA (Maven viene fornito di default in entrambi questi IDE)
- Jenkins in formato .war
- Chrome WebDriver corrispondente alla versione del browser Chrome sulla tua macchina
- Microsoft Edge Driver
- Account su LambdaTest (poiché i test vengono eseguiti su Selenium Grid basato su cloud di LambdaTest)
Dimostrazione dell’integrazione Selenium Maven Jenkins
Per risparmiare tempo, non vogliamo esaminare ogni passo della creazione di un progetto Maven. Nel caso vogliate un rapido riepilogo di Maven con Selenium, potete fare riferimento a questo tutorial Maven per l’automazione dei test di Selenium. I passi usati per creare un progetto Maven in IntelliJ IDEA sono simili a quelli usati per creare un progetto Maven in Eclipse IDE.
Test Suite – 1
Test Scenario – 1 (Chrome su Windows 10)
- Naviga verso questo URL- https://lambdatest.github.io/sample-todo-app/.
- Scegliete le prime due caselle di controllo.
- Inserite ‘Happy Testing at LambdaTest’ nella casella di testo sottostante con il seguente id = sampletodotext.
- Ora, cliccate sul pulsante Add e verificate se il testo è stato aggiunto o meno.
Scenario di test – 2 (Test su 4 diverse combinazioni di browser e sistema operativo)
- Naviga verso questo URL- https://www.google.com.
- Cerca “LambdaTest”.
- Clicca sul primo risultato del test.
- Ora, solleva un Assert se il titolo della pagina non corrisponde al titolo previsto.
Implementazione
Le dipendenze e i plugin appropriati devono essere aggiunti nel pom.xml del progetto. Ecco i pacchetti chiave (o jar) che fanno parte del pom.xml:
- Selenium 4 (Alpha)
- Framework TestNG (versione 6.9.10)
- plugin Maven Surefire per l’esecuzione di test suite che fa parte di testng.xml
- Maven Surefire Report plugin per generare il report dei risultati dei test in formato HTML
Se avete intenzione di aggiungere qualsiasi nuovo plugin o jar al pom.xml, cercate lo stesso sul Maven Repository e aggiungete la dipendenza/plugin corrispondente nella relativa sezione.
La suite di test contiene due casi di test, ovvero test_Selenium4_ToDoApp() & test_Selenium4_GoogleSearch(). Come mostrato di seguito, l’implementazione di questi casi di test è memorizzata in file separati, ovvero CrossBrowserTest.java e GoogleSearchTest.java, ed entrambi fanno parte del pacchetto org.selenium4.
Lo scenario di test test test_Selenium4_ToDoApp() è destinato ad essere eseguito su Chrome (Ultima versione) per Windows 10. D’altra parte, lo scenario di test test_Selenium4_GoogleSearch() deve essere eseguito su 4 diverse combinazioni di browser e OS cioè Chrome (ultimo) su Windows 10, Edge (84.0) su Windows 10, Chrome (ultimo) su macOS Mojave, e Firefox (ultimo) su OS X Mavericks.
Le voci in testng.xml per test_Selenium4_GoogleSearch() sono state allineate secondo le capacità del browser generate dal generatore di capacità LambdaTest. Di seguito sono riportate le capacità di esempio generate per Chrome (ultimo) & combinazione di Windows 10:
Nell’implementazione, useremmo gli ascoltatori di TestNG in Selenium WebDriver per i test di automazione. A livello di suite, definiamo i nomi delle classi per implementare gli ascoltatori nel file xml di TestNG. L’annotazione @listeners in TestNG è usata per aggiungere la classe org.selenium4.GoogleSearchTest.
Come mostrato di seguito, il nome del test ‘Google Search Test – 1’ prenderà parametri di input che specificano il browser, la versione, la piattaforma e la risoluzione del display. Questi valori saranno passati al metodo di test come argomenti usando annotazioni parametrizzate (cioè @org.testng.annotations.Parameters(value={“browser”, “version”, “platform”, “resolution”}).
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<listeners>
<listener class-name=”org.selenium4.GoogleSearchTest”/>
</listeners>
<test name=”Google Search Test – 1″>
<parametro name=”browser” value=”Chrome”/>
<parametro name=”version” value=”latest”/>
<parametro name=”piattaforma” value=”Windows 10″/>
<parametro name=”risoluzione” value=”1600×1200″/>
<classes>
<class name=”org.selenium4.GoogleSearchTest”/>
</classes>
</test>
|
CrossBrowserTest.java (implementazione dello scenario di test – 1)
GoogleSearchTest.java (Implementazione dello scenario di test – 2)
Code Walkthrough
Passo 1 – I pacchetti necessari sono importati prima che l’implementazione effettiva abbia inizio. Poiché il framework TestNG è usato per i test; quindi, anche i suoi pacchetti sono importati prima che le sue annotazioni possano essere usate.
1
2
3
4
5
|
import org.testng.annotations.AfterClass;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.Test;
import static org.junit.Assert.*;
import org.junit.Test.*;
|
Step 2 – IExecutionListener è usato per monitorare l’inizio e la fine della suite di test, poiché lo scenario di test verrebbe eseguito su diverse combinazioni di input che vengono passate attraverso il file xml TestNG.
L’IExecutionListener contiene due metodi – onExecutionStart() e onExecutionFinish(). onExecutionStart() è invocato prima dell’inizio del test e onExecutionFinish() è invocato una volta che i test/le suite di test hanno finito l’esecuzione.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
public class GoogleSearchTest implements IExecutionListener {
/* protected static EdgeDriver driver; */
String URL = “https://www.google.com/”;
…………………………..
…………………………..
…………………………..
@Override
public void onExecutionStart() {
System.out.println(“onExecutionStart”);
}
@Override
public void onExecutionFinish() {
System.out.println(“onExecutionFinish”);
}
|
Passo 3 – Il metodo implementato sotto l’annotazione @BeforeTest verrà eseguito prima di qualsiasi metodo di test appartenente alla classe sotto quel tag. Dato che stiamo usando test parametrici con TestNG, l’annotazione @Parameters(value={“browser”, “version”, “platform”, “resolution”}) viene aggiunta al metodo di test.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
public class GoogleSearchTest implements IExecutionListener {
/* protected static EdgeDriver driver; */
String URL = “https://www.google.com/”;
String search_string = “LambdaTest”;
WebDriver driver = null;
…………………………
…………………………
public static String status = “passed”;
public static String username = “user-name”;
public static String access_key = “access-key”;
…………………………
…………………………
@BeforeTest
@Parameters(value={“browser”, “version”, “platform”, “resolution”})
public void testSetUp(String browser, String version, String platform, String resolution) throws Exception {
…………………………
…………………………
}
|
Questi parametri verrebbero passati valori da testng.xml, esempio di parametro mostrato sotto:
Step 4 – Il metodo testSetUp è un metodo parametrizzato che prende iterativamente i parametri di test da TestNG.xml fino alla fine della suite di test.
Come i test sono eseguiti sul cloud Selenium Grid su LambdaTest, le credenziali consistono in un nome utente &un token di accesso che può essere utilizzato per accedere alla Grid LambdaTest – @hub.lambdatest.com/wd/hub.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
public void testSetUp(String browser, String version, String platform, String resolution) throws Exception {
DesiredCapabilities capabilities = new DesiredCapabilities();
capabilities.setCapability(“build”, “Google Search – Maven Parallel Testing with Jenkins Pipeline”);
capabilities.setCapability(“name”, “Google Search – Maven Parallel Testing with Jenkins Pipeline”);
…………………………
…………………………
try {
driver = new RemoteWebDriver(new URL(“http://” + username + “:” + access_key + “@hub.lambdatest.com/wd/hub”), capabilities);
} catch (MalformedURLException e) {
System.out.println(“Invalid grid URL”);
}
System.out.println(“Sessione avviata”);
|
L’API RemoteWebDrive usa l’URL remoto e le capacità del browser che sono generate usando il generatore di capacità LambdaTest e passate al metodo sotto forma di parametri di input.
1
2
3
4
|
try {
driver = new RemoteWebDriver(new URL(“http://” + username + “:” + access_key + “@hub.lambdatest.com/wd/hub”), capabilities);
}
catch (MalformedURLException e)
|
Step 5 – Il metodo di test è implementato sotto l’annotazione @Test
. I metodi appropriati di Selenium (findElement, sendKeys, submit, e altri) sono usati per localizzare l’elemento web ed eseguire azioni appropriate sullo stesso.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
@Test
public void test_Selenium4_GoogleSearch() throws InterruptedException {
driver.navigate().to(URL);
driver.manage().window().maximize();
try {
/* Inserire il termine di ricerca nella Google Search Box */
search_box = driver.findElement(By.xpath(“//input”));
search_box.sendKeys(search_string);
search_box.submit();
……………………………………
……………………………………
}
……………………………………
……………………………………
}
|
Passo 6 – Bloccare i ritardi non è una buona pratica di programmazione, ma abbiamo aggiunto alcuni ritardi per osservare l’uscita.
1
2
3
4
5
6
7
|
WebElement lt_link = driver.findElement(By.xpath(“//h3”));
lt_link.click();
/* Non è una buona pratica di programmazione, aggiunta per dimostrazione */
Thread.sleep(5000);
……………………………………
……………………………………
|
Step 7 – Il metodo che è implementato sotto l’annotazione @AfterTest
libera le risorse allocate dal WebDriver corrispondente istanziato.
1
2
3
4
5
6
7
|
@AfterClass
public void tearDown() {
if (driver != null) {
((JavascriptExecutor) driver).executeScript(“lambda-status=” + status);
driver.quit();
}
}
|
Test Suite – 2
Scenario di test – 1 (Chrome su Windows 10)
- Naviga all’URL https://lambdatest.com
- Controlla la pagina Title
- Confronta il titolo della pagina con il titolo previsto
- Asserisci se i titoli non corrispondono
Implementazione
E’ lo stesso che viene usato per Test Suite-1, tranne che per l’artifactId e il groupID.
CrossBrowserTest.java
Per la dimostrazione di Maven e Jenkins con Selenium, eseguiremo queste due suite di test in parallelo usando il progetto FreeStyle e Jenkins Pipeline.
Woo-hoo! Grazie per esserti iscritto alla newsletter settimanale di LambdaTest!
Impostare Jenkins per il progetto Jenkins Selenium
Prima di creare un nuovo lavoro in Jenkins che costruisca il progetto menzionato prima, dobbiamo impostare l’ambiente Jenkins.
Step 1: Il percorso di installazione di JDK deve essere aggiunto alla variabile di ambiente del sistema. Questo è richiesto anche per JRE (Java Runtime Environment).
Step 2: Scaricare Jenkins in formato .war e avvia Jenkins eseguendo il seguente comando sul terminale:
1
|
java -Dhudson.model.DirectoryBrowserSupport.CSP=”sandbox allow-scripts allow-popups allow-popups-to-escape-sandbox; style-src ‘unsafe-inline’ *;” -Dsvnkit.http.sslProtocols=TLSv1 -jar Jenkins.war –httpPort=9090
|
Invece di 8080 (numero di porta predefinito usato da Jenkins), avviamo il servizio Jenkins sulla porta 9090.
Step 3: Visita localhost:9090
nel browser web per iniziare a usare Jenkins.
Crea un nuovo utente (con privilegi di amministratore). Effettuare il login usando quel nome utente per continuare a usare Jenkins.
Passo 4: Poiché il progetto sta usando Maven e Jenkins con Selenium, le impostazioni globali e i percorsi per Java & Maven devono essere configurati in Jenkins. Per configurare queste impostazioni, vai a ‘Configure System’ nella sezione ‘System Configuration’.
Nella voce intitolata ‘Proprietà globali’, aggiungi le seguenti variabili d’ambiente:
1
2
|
JAVA_HOME – <Posizione dove è installato JDK>
MAVEN_HOME – <Posizione dove è installato Maven>
|
Nel nostro caso le voci sono le seguenti:
1
2
|
JAVA_HOME – C:\Program Files\Java\jdk1.8.0_251
MAVEN_HOME – C:\apache-maven\apache-maven-3.6.3\
|
Clicca su Apply e Save.
L’aggiunta di queste variabili d’ambiente nella System Configuration rende le impostazioni pubbliche (cioè.e. può essere usato per il progetto Jenkins FreeStyle e il progetto Jenkins Pipeline).
Step 5: Il Plugin HTML Publisher deve essere installato prima che l’azione post-build per i test possa essere eseguita. Lo stesso può essere fatto navigando in ‘Manage Plugins’ e cercando ‘HTML Publisher Plugin’ nella scheda ‘Available’. Clicca su ‘Install’ per installare il plugin.
Nota: Per i test cross browser, si raccomanda di usare Jenkins nel formato .war poiché i test vengono eseguiti in modalità non-headless solo quando Jenkins è usato nel formato .war.
Selenium Maven Jenkins Integration Using FreeStyle Project
Per creare un progetto FreeStyle che usa Selenium Maven Jenkins integration come dimostrazione, eseguire i seguenti passi su Jenkins UI (i.e. localhost:9090/
)
(Nota – Il numero di porta varierà in base alla porta utilizzata da Jenkins)
Passo 1: Nella ‘Jenkins UI’, clicca su ‘New Item’.
Passo 2: Inserisci il nome del lavoro come ‘LambdaTest – Selenium Maven Jenkins integration (Maven Project)’ e seleziona il progetto ‘FreeStyle’.
Jenkins fornisce anche un’opzione per creare un progetto ‘Maven’ dove le impostazioni di configurazione richieste per impostare il progetto sono minime. Tuttavia, per questa dimostrazione, abbiamo usato un progetto ‘FreeStyle’.
Step 3: Vai alla sezione ‘Build’ ? ‘Invoke top-level Maven targets’. La versione di Maven dovrebbe puntare alla versione di Maven installata sulla macchina. Nel nostro caso, è Maven 3.6.3.
Step 4: Clicca su ‘Advanced’ per impostare gli obiettivi, imposta la posizione dei file POM per le due suite di test. Nel nostro caso, le posizioni del progetto sono le seguenti:
Siccome vogliamo eseguire build parallele, usiamo la seguente opzione con il comando mvn:
1
|
mvn -T 4 clean install
|
Questo comando eseguirà build con 4 thread. Nella sezione “Obiettivi”, dovresti inserire -T 4 clean install. Lo stesso obiettivo è impostato per le build di Maven per entrambi i progetti. In ‘POM’, dai la posizione assoluta di pom.xml
(cioè Build 1 – C:\Users\Lenovo\IdeaProjects\Maven_Jenkins\pom.xml
Build 2 – C:\Users\Lenovo\IdeaProjects\Maven_Jenkins_2\pom.xml)
Step 5: L’azione ‘post-Build’ è di pubblicare report HTML che danno informazioni sullo scenario generale dei test (es. numero di test passati/falliti/salvati, ecc.). Seleziona ‘Publish HTML Reports’ in ‘Add post-build action’.
Step 6: Il plugin Maven Surefire Report analizza i file TEST-*.xml generati sotto ${project_dir}/target/surefire-reports e li rende usando DOXIA. In ‘HTML directory to archive’, inserite il percorso assoluto di quella posizione che contiene i report surefire.
Per Test Suite 1:
1
2
3
|
Directory HTML da archiviare – ${project_dir_1}/target/surefire-reports
Pagina/e di indice – index.html
Titolo del report – Test Scenario 1 Report
|
Per Test Suite 2:
1
2
3
|
Directory HTML da archiviare – ${project_dir_2}/target/surefire-reports
Pagina/e di indice – index.html
Titolo del report – Test Scenario 2 Report
|
Passo 7: Il progetto è ora pronto per la costruzione. Clicca sull’opzione ‘Build Now’ per avviare la compilazione.
Step 8: Clicca su ‘Console Output’ per assistere al progresso delle fasi di compilazione, test e report.
Passo 9: Come si vede nel ‘Console logs; i test sono eseguiti con successo – cinque casi di test come parte della prima suite di test e un caso di test come parte della seconda suite di test.
Qui ci sono le schermate dei rapporti HTML che sono generati per le due suite di test dal plugin HTML Publisher.
Selenium Maven Jenkins Integration Using Jenkins Pipeline
In questa sezione di Maven e Jenkins con Selenium dimostrazione, useremo la Jenkins Pipeline che usa il Domain Specific Language (DSL) per realizzare Pipeline come codice.
La definizione di una Jenkins Pipeline è normalmente scritta in un file chiamato Jenkinsfile. Questo file conterrebbe i passi necessari per eseguire la Jenkins Pipeline. Per un rapido riepilogo sulla Jenkins Pipeline dichiarativa, puoi controllare questo tutorial sulla Jenkins Pipeline.
Per integrare Maven e Selenium con la Jenkins Pipeline, devi eseguire i passi menzionati di seguito:
Passo 1: Crea un nuovo elemento intitolato ‘LambdaTest – Selenium Maven Jenkins integration (Pipeline Project)’ di tipo ‘Pipeline’.
Step 2: In Pipeline definition, incolla il contenuto di Jenkinsfile come mostrato qui sotto. Cliccate su Apply e Save.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
|
pipeline {
agente qualsiasi
strumenti {
maven ‘MAVEN_3.6.3’
jdk ‘JDK_1.8.0_251’
}
stages {
stage(‘Run Tests’)
environment {
PROJECT_DIR_1 = “C:\Users\Lenovo\IdeaProjects\Maven_Jenkins”
PROJECT_DIR_2 = “C:\Users\Lenovo\IdeaProjects\Maven_Jenkins_2”
}
parallelo {
stage(‘Test Scenario 1’) {
agent {
label “Slave_1”
}
steps {
echo ‘maven clean’
bat ‘ mvn -f %PROJECT_DIR_1%\pom.xml clean install’
}
post {
successo
publishHTML ()
}
}
}
stage(‘Test Scenario 2’) {
agent {
label “Slave_2”
}
steps {
echo ‘maven clean’
bat ‘ mvn -f %PROJECT_DIR_2%\\pom.xml clean install’
}
post {
successo {
publishHTML ()
}
}
}
}
}
}
}
|
Step 3: Nella sezione post-build, l’HTML Publisher Plugin è usato per creare i test report post-esecuzione per i due scenari di test.
Pipeline Walkthrough
Step 1: Questo specifico lavoro Jenkins può essere eseguito su qualsiasi agente. La sezione con la direttiva tools contiene tutti gli strumenti che devono essere installati automaticamente. Lo stesso viene poi aggiunto alla variabile d’ambiente PATH.
1
2
3
4
5
6
|
pipeline {
agente qualsiasi
strumenti {
maven ‘MAVEN_3.6.3’
jdk ‘JDK_1.8.0_251’
}
|
Nella macchina dove verranno eseguiti i test, JDK 1.8.0_251 e Maven 3.6.3 sono installati. Gli alias maven e jdk puntano alle rispettive versioni di Maven e JDK.
Step 2: La direttiva ambiente è usata per definire le variabili d’ambiente PROJECT_DIR_1 e PROJECT_DIR_2 che puntano alla posizione in cui sono presenti i progetti Java. Queste variabili d’ambiente possono essere usate per tutti i passi o per passi specifici della fase, poiché sono definite nella fase principale ‘Run Tests.’
1
2
3
4
5
6
|
stages {
stage(‘Run Tests’)
environment {
PROJECT_DIR_1 = “C:\Users\Lenovo\IdeaProjects\Maven_Jenkins”
PROJECT_DIR_2 = “C:\Users\Lenovo\IdeaProjects\Maven_Jenkins_2”
}
|
Step 3: La direttiva parallela in Jenkins è usata per eseguire le fasi della Pipeline in parallelo. Nel nostro caso, la Pipeline di Jenkins consiste di due fasi – Test Scenario 1 e Test Scenario 2.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
stages {3567>
stage(‘Run Tests’) {
environment {
PROJECT_DIR_1 = “C:\Users\Lenovo\IdeaProjects\Maven_Jenkins”
PROJECT_DIR_2 = “C:\Users\Lenovo\IdeaProjects\Maven_Jenkins_2”
}
parallelo {
stage(‘Test Scenario 1’) {
…………………………………..
…………………………………..
}
stage(‘Test Scenario 2’) {
…………………………………..
…………………………………..
}
}
}
}
|
Step 4: Le azioni eseguite in entrambe le fasi sono esattamente simili, tranne che sono eseguite su progetti diversi. La fase ‘Test Scenario 1
‘ viene eseguita sul nodo ‘Slave_1
‘ e la fase ‘Test Scenario 2
‘ viene eseguita sul nodo ‘Slave_2
‘.
1
2
3
4
5
6
7
8
9
10
11
|
parallelo {
stage(‘Test Scenario 1’) {
agente {
etichetta “Slave_1”
}
………….
………….
stage(‘Test Scenario 2’) {
agente {
etichetta “Slave_2”
}
|
Nel caso in cui tu intenda eseguire la pipeline su qualsiasi agente, puoi saltare l’uso di un particolare nome di agente in queste fasi. Puoi fare riferimento al nostro blog What is Jenkins per capire la creazione di Nodi in Jenkins.
Nel nostro caso, abbiamo creato due Nodi (Slave_1 e Slave_2) e li abbiamo messi online prima di eseguire i test.
Step 5: Nel prossimo passo, viene attivata la costruzione. Il comando mvn clean install viene quindi eseguito su pom.xml che è presente nella directory del progetto. Stiamo usando una macchina Windows per l’esecuzione, quindi abbiamo usato il comando bat (o batch) per innescare la costruzione di Maven.
1
2
3
4
|
passi {
echo ‘maven clean’
bat ‘ mvn -f %PROJECT_DIR_1%\pom.xml clean install’
}
|
Passo 6: L’azione post-build è usata per pubblicare rapporti HTML per le rispettive fasi. Le azioni sono aggiunte sotto la direttiva ‘post’. Vogliamo invocare la creazione del rapporto di prova solo se la costruzione ha successo. Quindi, le azioni sono sotto la direttiva success.
Come visto nella dimostrazione usando il progetto FreeStyle, reportDir è impostato al percorso in cui vengono generati i report surefire (cioè ${project_dir}/target/surefire-reports). Il campo reportFiles è impostato su index.html (cioè ${project_dir}/target/surefire-reports/index.html).
1
2
3
4
5
6
7
8
9
10
11
12
13
|
post {
successo {
publishHTML ()
}
}
|
Una volta che la Pipeline è stata aggiunta a Jenkinsfile, clicca su ‘Build Now’ per iniziare il processo di compilazione.
Puoi passare il mouse su qualsiasi Stage e cliccare su ‘Logs’ per dare un’occhiata al progresso di esecuzione di quel particolare Stage. Come si vede dall’istantanea della fase, le due fasi sono eseguite in parallelo.
Come stiamo usando fasi parallele con Pipeline dichiarativa in Jenkins, i rispettivi casi di test sono eseguiti in parallelo sulla griglia Selenium basata sul cloud su LambdaTest. Come mostrato di seguito, il nostro piano su LambdaTest supporta un massimo di cinque test da eseguire in parallelo.
Come mostrato di seguito, i test sono stati eseguiti con successo.
Il tempo di esecuzione totale era di circa 6 minuti. Puoi passare il mouse su qualsiasi stadio per visualizzare i log associati a quello stadio.
Come si vede nei log troncati, è evidente che i passi nelle due fasi venivano eseguiti in parallelo:
Ecco la schermata dei rapporti HTML che vengono generati come parte dell’azione post-costruzione:
Wrapping up
Eseguire i test di Selenium in Jenkins dà la flessibilità di eseguire i test ogni volta che c’è un cambiamento nel software, e questi cambiamenti devono essere testati con diverse combinazioni di input. Maven è usato nei progetti Java, poiché facilita il compito di gestire le dipendenze attraverso il file pom.xml.
I progetti Freestyle in Jenkins dovrebbero essere usati per progetti che non sono di alta complessità. Jenkins Pipeline dovrebbe essere usato quando si vuole definire la pipeline di distribuzione come codice. La direttiva parallela in Jenkins Pipeline dovrebbe essere usata per sfruttare l’esecuzione parallela di Stages in Jenkins. Jenkins Pipeline può essere integrato con un Selenium Grid basato su cloud come LambdaTest, che permette anche di integrare Maven e Jenkins con Selenium in modo più efficiente.
Speriamo che seguendo questo tutorial, potrete facilmente integrare Maven e Jenkins con Selenium. Grazie per aver letto!
Himanshu Sheth
Con oltre 7 anni di esperienza nell’automazione dei test, BDD, TDD, Himanshu Sheth lavora come ingegnere di automazione con LambdaTest. È anche un appassionato blogger.
Lascia un commento