Comment intégrer Jenkins et Maven avec Selenium ?

Jenkins est l’un des outils populaires pour l’intégration continue, la gestion des builds et les tests d’automatisation. Maven est un outil d’automatisation de build populaire qui est largement utilisé pour les projets Java. La combinaison de Selenium, Maven, l’intégration Jenkins est le summum de l’intégration et du déploiement continus.

Dans le cadre des tests d’automatisation, nous sommes sûrs que votre équipe propose de nombreux scripts d’automatisation de test Selenium tous les deux jours. Comme Selenium lui-même n’est pas utilisé pour l’intégration continue, Selenium, Maven et l’intégration Jenkins sont exploités pour la gestion des builds et l’intégration continue. Dans cet article, nous examinons l’utilisation de Maven et Jenkins avec Selenium.

Un résumé rapide de l’article de blog est ci-dessous:

Overview Of Selenium, Maven, & Jenkins

Maven est un outil d’automatisation de build populaire qui est principalement utilisé pour les projets Java. L’avantage d’utiliser Maven est que les bibliothèques et les plugins Java sont téléchargés sur une base dynamique à partir du dépôt central Maven 2.

Les dépendances et autres informations essentielles liées à la construction sont stockées dans un fichier pom.xml du projet. Une fois téléchargées, les dépendances sont stockées dans un cache local (.M2 repository), et le même est utilisé pour la génération de build. Cela simplifie le processus de construction, car toute nouvelle dépendance du projet doit être ajoutée uniquement dans pom.xml, c’est-à-dire qu’aucun téléchargement manuel et aucun paquet d’installation n’est nécessaire.

Selenium est un cadre d’automatisation des tests largement utilisé pour valider les applications Web à travers différentes combinaisons de navigateurs, de plates-formes et de dispositifs (ou émulateurs). Vous pouvez vous référer à nos blogs sur la façon dont Selenium Grid peut être utilisé pour les tests automatisés de navigateur.

Jenkins est un outil CI/CD open-source qui aide à l’automatisation des activités liées à la construction, au test et au déploiement. Jenkins dispose d’un vaste écosystème de plugins, est open-source et dispose d’une communauté passionnée – des facteurs qui peuvent être attribués aux fonctionnalités de Jenkins.

Dans ce blog Maven et Jenkins avec Selenium, nous utiliserions TestNG, qui est un cadre de test populaire inspiré de JUnit. Il est largement utilisé pour les domaines de test tels que les tests fonctionnels, les tests de bout en bout, et plus encore.

Ce sont les ensembles d’outils que nous utiliserions dans la démonstration :

• Maven – Outil de gestion de projet en Java
• TestNG – Cadre populaire d’automatisation des tests
• Selenium WebDriver – Bibliothèque principalement utilisée pour l’automatisation des interactions avec le navigateur
• Jenkins – Outil d’intégration continue (CI) et de déploiement continu (CD)

Voici le flux global d’informations lorsque Selenium, Maven, et Jenkins sont intégrés :

• Une fois que le développeur pousse le code dans le référentiel (par ex.g., GitHub), une construction Jenkins est déclenchée.
• Maven télécharge les paquets de bibliothèques dépendantes & et commence à exécuter la construction. Les informations relatives à la suite de tests sont disponibles dans testing.xml, et les mêmes sont également utilisées dans pom.xml.
• Un objectif de build (par exemple, installer) pour exécuter les tests automatisés est défini. La même chose est réalisée par le maven-surefire-plugin.
• Le maven-surefire-plugin indique à TestNG d’exécuter les tests qui sont sous l’annotation @Test.
• Selon l’AUT (application sous test) et le navigateur (& combinaison d’OS) sur lesquels les tests inter-navigateurs sont effectués, le Selenium WebDriver invoque l’instance de navigateur correspondante et exécute les mêmes tests d’automatisation.
• Les résultats des tests sont publiés dans des rapports HTML, car le plugin HTML Publisher est utilisé pour la génération de rapports.
• Même si un seul cas de test a échoué, le test complet est marqué du statut ‘Échec.’

Avantages de l’utilisation de Maven & Jenkins avec Selenium

Avant de démontrer l’utilisation de l’intégration Selenium Maven Jenkins, nous allons jeter un coup d’œil aux principaux avantages de l’utilisation de Maven et Jenkins avec Selenium :

• Chaque fois qu’un changement est effectué dans l’implémentation, les changements sont déployés sur l’environnement de test. Les tests d’automatisation sont effectués en continu, et les développeurs sont tenus informés des résultats de la construction et de l’étape de test.
• Les suites de test qui comprennent de nombreux scénarios de test (ou combinaisons de test) pourraient prendre une durée plus longue pour les tests d’automatisation. Une exécution nocturne peut être planifiée pour la construction et l’exécution sur le serveur Jenkins dans de tels cas.
• Comme Maven utilise pom.xml, il réduit la dépendance globale du téléchargement manuel des fichiers jar. De plus, le type ‘Projet Maven’ dans Jenkins aide à démarrer l’intégration Selenium Maven, Jenkins avec quelques paramètres de configuration.
• La configuration de l’intégration Selenium Maven Jenkins est adaptée aux équipes de développement et de test réparties sur différents sites géographiques.

Prérequis pour le projet Jenkins Selenium

Pour la démonstration de Maven et Jenkins avec Selenium, les logiciels suivants doivent être installés (ou disponibles) sur la machine à partir de laquelle les tests sont déclenchés :

• Eclipse IDE ou IntelliJ IDEA (Maven vient par défaut dans ces deux IDE)
• Jenkins au format .war
• Chrome WebDriver correspondant à la version du navigateur Chrome sur votre machine
• Microsoft Edge Driver
• Compte sur LambdaTest (car les tests sont exécutés sur la grille Selenium basée sur le cloud de LambdaTest)

Démonstration de l’intégration Selenium Maven Jenkins

Pour gagner du temps, nous ne nous pencherions pas sur chaque étape de la création d’un projet Maven. Au cas où vous souhaiteriez un récapitulatif rapide de Maven avec Selenium, vous pouvez vous référer à ce tutoriel Maven pour l’automatisation des tests Selenium. Les étapes utilisées pour créer un projet Maven dans IntelliJ IDEA sont similaires à celles utilisées pour créer un projet Maven dans l’IDE Eclipse.

Suite de test – 1

Scénario de test – 1 (Chrome sur Windows 10)

1. Naviguez vers cette URL- https://lambdatest.github.io/sample-todo-app/.
2. Choisissez les deux premières cases à cocher.
3. Entrez ‘Happy Testing at LambdaTest’ dans la zone de texte ci-dessous avec l’id suivant = sampletodotext.
4. Maintenant, cliquez sur le bouton Ajouter et vérifiez si le texte a été ajouté ou non.

Scénario de test – 2 (Tests sur 4 combinaisons différentes de navigateur et d’OS)

1. Naviguez vers cette URL- https://www.google.com.
2. Recherchez « LambdaTest ».
3. Cliquez sur le premier résultat de test.
4. Maintenant, levez un Assert si le titre de la page ne correspond pas au titre attendu.

Mise en œuvre

Les dépendances et plugins appropriés doivent être ajoutés dans le pom.xml du projet. Voici les principaux paquets (ou jars) qui font partie de pom.xml:

• Selenium 4 (Alpha)
• Cadre TestNG (version 6.9.10)
• Plugin Maven Surefire pour l’exécution de la suite de tests qui fait partie de testng.xml
• Plugin Maven Surefire Report pour générer le rapport des résultats de test dans un format HTML

Si vous avez l’intention d’ajouter un nouveau plugin ou jar au pom.xml, recherchez-le sur le Maven Repository et ajoutez la dépendance/le plugin correspondant dans la section pertinente.

La suite de tests contient deux cas de test, à savoir test_Selenium4_ToDoApp() & test_Selenium4_GoogleSearch(). Comme indiqué ci-dessous, la mise en œuvre de ces cas de test est stockée dans des fichiers distincts, à savoir CrossBrowserTest.java et GoogleSearchTest.java, et les deux font partie du paquet org.selenium4.

Le scénario de test test_Selenium4_ToDoApp() est destiné à être exécuté sur Chrome (Dernière version) pour Windows 10. D’autre part, le scénario de test test_Selenium4_GoogleSearch() doit être exécuté sur 4 combinaisons différentes de navigateur et d’OS, à savoir Chrome (dernière version) sur Windows 10, Edge (84.0) sur Windows 10, Chrome (dernière version) sur macOS Mojave, et Firefox (dernière version) sur OS X Mavericks.

Les entrées dans testng.xml pour test_Selenium4_GoogleSearch() ont été alignées en fonction des capacités du navigateur générées par le générateur de capacités LambdaTest. Montré ci-dessous sont les exemples de capacités générées pour Chrome (dernier) & Windows 10 combinaison:

Dans l’implémentation, nous utiliserions les écouteurs TestNG dans Selenium WebDriver pour les tests d’automatisation. Au niveau de la suite, nous définissons les noms de classe pour mettre en œuvre les listeners dans le fichier xml de TestNG. L’annotation @listeners dans TestNG est utilisée pour ajouter la classe org.selenium4.GoogleSearchTest.

Comme indiqué ci-dessous, le nom du test ‘Google Search Test – 1’ prendra des paramètres d’entrée qui spécifient le navigateur, la version, la plate-forme et la résolution d’affichage. Ces valeurs seraient transmises à la méthode de test en tant qu’arguments en utilisant des annotations paramétrées (c’est-à-dire @org.testng.annotations.Parameters(value={« browser », « version », « platform », « resolution »}).

CrossBrowserTest.java (Mise en oeuvre du scénario de test – 1)

GoogleSearchTest.java (Mise en œuvre du scénario de test – 2)

Code Walkthrough

Etape 1 – Les paquets nécessaires sont importés avant que la mise en œuvre réelle ne démarre. Puisque le framework TestNG est utilisé pour les tests ; par conséquent, ses packages sont également importés avant que ses annotations puissent être utilisées.

Étape 2 – L’IExecutionListener est utilisé pour surveiller le début et la fin de la suite de tests, car le scénario de test serait exécuté sur différentes combinaisons d’entrée qui sont passées par le fichier xml TestNG.

Le IExecutionListener contient deux méthodes – onExecutionStart() et onExecutionFinish(). onExecutionStart() est invoqué avant le début du test et onExecutionFinish() est invoqué une fois que les tests/suites de tests ont terminé l’exécution.

Étape 3 – La méthode implémentée sous l’annotation @BeforeTest s’exécutera avant l’exécution de toute méthode de test appartenant à la classe sous cette balise. Comme nous utilisons des tests paramétrés avec TestNG, l’annotation @Parameters(value={« browser », « version », « platform », « resolution »}) est ajoutée à la méthode de test.

Ces paramètres se verraient passer des valeurs de testng.xml, exemple de paramètre présenté ci-dessous :

Etape 4 – La méthode testSetUp est une méthode paramétrée qui prend itérativement les paramètres de test de TestNG.xml jusqu’à ce que la fin de la suite de tests soit rencontrée.

Comme les tests sont exécutés sur le cloud Selenium Grid sur LambdaTest, les informations d’identification consistent en un nom d’utilisateur & un jeton d’accès qui peut être utilisé pour accéder à la grille LambdaTest – @hub.lambdatest.com/wd/hub.

L’API RemoteWebDrive utilise l’URL distante et les capacités du navigateur qui sont générées à l’aide du générateur de capacités LambdaTest et transmises à la méthode sous la forme de paramètres d’entrée.

Étape 5 – La méthode de test est implémentée sous l’annotation @Test. Les méthodes Selenium appropriées (findElement, sendKeys, submit, et plus) sont utilisées pour localiser l’élément Web et effectuer les actions appropriées sur celui-ci.

Étape 6 – Le blocage des délais n’est pas une bonne pratique de programmation, mais nous avons ajouté quelques délais pour observer la sortie.

Etape 7 – La méthode qui est implémentée sous l’annotation @AfterTest libère les ressources allouées par le WebDriver correspondant instancié.

Suite de tests – 2

Scénario de tests – 1 (Chrome sur Windows 10)

1. Naviguer vers l’URL https://lambdatest.com
2. Vérifier la page. Title
3. Comparer le titre de la page avec le titre attendu
4. Assert si les titres ne correspondent pas

Mise en œuvre

C’est le même que celui qui est utilisé pour la suite de tests-.1, sauf pour l’artifactId et le groupID.

CrossBrowserTest.java

Pour la démonstration de Maven et Jenkins avec Selenium, nous exécuterions ces deux suites de tests en parallèle en utilisant le projet FreeStyle et le pipeline Jenkins.

Woo-hoo ! Merci de vous être inscrit à la newsletter hebdomadaire de LambdaTest !

Configuration de Jenkins pour le projet Jenkins Selenium

Avant de créer un nouveau job dans Jenkins qui construit le projet mentionné précédemment, nous devons configurer l’environnement Jenkins.

Etape 1 : Le chemin d’installation de JDK doit être ajouté à la variable d’environnement système. Ceci est également nécessaire pour JRE (Java Runtime Environment).

Etape 2 : Télécharger Jenkins au format .war et démarrez Jenkins en exécutant la commande suivante sur le terminal:

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

Au lieu de 8080 (numéro de port par défaut utilisé par Jenkins), nous démarrons le service Jenkins sur le port 9090.

Étape 3 : Visitez localhost:9090 dans le navigateur web pour commencer à utiliser Jenkins.

Créer un nouvel utilisateur (avec des privilèges d’administrateur). Connectez-vous en utilisant ce nom d’utilisateur pour continuer à utiliser Jenkins.

Étape 4 : Comme le projet utilise Maven et Jenkins avec Selenium, les paramètres globaux et les chemins pour Java & Maven doivent être configurés dans Jenkins. Pour configurer ces paramètres, naviguez vers ‘Configurer le système’ dans la section ‘Configuration du système’.

Dans l’élément intitulé ‘Propriétés globales’, ajoutez les variables d’environnement suivantes :

1 2	JAVA_HOME – <L’emplacement où JDK est installé> MAVEN_HOME – <L’emplacement où Maven est installé>

Dans notre cas, les entrées sont les suivantes :

1 2	JAVA_HOME – C:\Program Files\Java\jdk1.8.0_251 MAVEN_HOME – C:\apache-maven\apache-maven-3.6.3\

Cliquez sur Appliquer et Enregistrer.

L’ajout de ces variables d’environnement dans la configuration du système rend les paramètres publics (c’est-à-dire.e. peut être utilisé pour le projet Jenkins FreeStyle et le projet Jenkins Pipeline).

Etape 5 : Le plugin HTML Publisher doit être installé avant que l’action post-build pour les tests puisse être effectuée. La même chose peut être faite en naviguant dans ‘Manage Plugins’ et en recherchant ‘HTML Publisher Plugin’ dans l’onglet ‘Available’. Cliquez sur ‘Installer’ pour installer le plugin.

Note : Pour les tests entre navigateurs, il est recommandé d’utiliser Jenkins au format .war car les tests sont exécutés en mode non-headless uniquement lorsque Jenkins est utilisé au format .war.

Selenium Maven Jenkins Integration Using FreeStyle Project

Pour créer un projet FreeStyle qui utilise l’intégration Selenium Maven Jenkins comme démonstration, effectuez les étapes suivantes sur l’interface utilisateur de Jenkins (i.e. localhost:9090/)

(Note – Le numéro de port variera en fonction du port utilisé par Jenkins)

Étape 1 : Dans le ‘Jenkins UI’, cliquez sur ‘New Item’.

Étape 2 : Entrez le nom du travail comme ‘LambdaTest – Intégration Selenium Maven Jenkins (Projet Maven)’ et sélectionnez le projet ‘FreeStyle’.

Jenkins offre également une option pour créer un projet ‘Maven’ où les paramètres de configuration requis pour la mise en place du projet sont minimes. Cependant, pour cette démonstration, nous avons utilisé un projet ‘FreeStyle’.

Etape 3 : Allez dans l’onglet ‘Build’ ? ‘Invoke top-level Maven targets’. La version de Maven doit pointer vers la version de Maven installée sur la machine. Dans notre cas, c’est Maven 3.6.3.

Étape 4 : Cliquez sur ‘Advanced’ pour définir les objectifs, définir l’emplacement des fichiers POM pour les deux suites de test. Dans notre cas, les emplacements du projet sont ci-dessous:

Comme nous voulons effectuer des constructions parallèles, nous utilisons l’option suivante avec la commande mvn :

1	mvn -T 4 clean install

Cette commande effectuera des constructions avec 4 fils. Dans la section ‘Objectifs’, vous devez entrer -T 4 clean install. Le même objectif est défini pour les builds Maven pour les deux projets. Dans ‘POM’, indiquez l’emplacement absolu de pom.xml

(c’est-à-dire Build 1 – C:\Users\Lenovo\IdeaProjects\Maven_Jenkins\pom.xml

Build 2 – C:\Users\Lenovo\IdeaProjects\Maven_Jenkins_2\pom.xml)

Etape 5 : L »action post-Build’ consiste à publier des rapports HTML qui donnent des informations sur le scénario de test global (c’est-à-dire le nombre de tests réussis/échecs/écartés, etc.). Sélectionnez ‘Publish HTML Reports’ dans ‘Add post-build action’.

Etape 6 : Le plugin Maven Surefire Report analyse les fichiers TEST-*.xml générés sous ${project_dir}/target/surefire-reports et les rend en utilisant DOXIA. Dans ‘HTML directory to archive’, entrez le chemin absolu de cet emplacement qui contient les rapports surefire.

Pour la suite de tests 1 :

1 2 3

Répertoire HTML à archiver – ${projet_dir_1}/target/surefire-reports Page(s) d’index – index.html Titre du rapport – Rapport du scénario de test 1

Pour la suite de tests 2 :

1 2 3

Répertoire HTML à archiver – ${project_dir_2}/target/surefire-reports Page(s) d’index – index.html Titre du rapport – Rapport du scénario de test 2

Étape 7 : Le projet est maintenant prêt à être construit. Cliquez sur l’option ‘Build Now’ pour déclencher la construction.

Etape 8 : Cliquez sur la ‘Console Output’ pour assister à la progression des étapes de construction, de test et de rapport.

Étape 9 : Comme on le voit dans les ‘journaux de la console ; les tests sont exécutés avec succès – cinq cas de test dans le cadre de la première suite de tests et un cas de test dans le cadre de la deuxième suite de tests.

Voici les captures d’écran des rapports HTML qui sont générés pour les deux suites de tests par le plugin HTML Publisher.

Rapport pour le scénario de test – 1

Rapport pour le scénario de test – 2

Selenium Maven Jenkins Integration Using Jenkins Pipeline

Dans cette section de démonstration de Maven et Jenkins avec Selenium, nous utiliserions le pipeline Jenkins qui utilise un langage spécifique au domaine (DSL) pour réaliser le pipeline en tant que code.

La définition d’un Pipeline Jenkins est normalement écrite dans un fichier nommé Jenkinsfile. Ce fichier contiendrait les étapes nécessaires à l’exécution du pipeline Jenkins. Pour un récapitulatif rapide sur le Pipeline Jenkins déclaratif, vous pouvez consulter ce tutoriel sur le Pipeline Jenkins.

Pour intégrer Maven et Selenium au Pipeline Jenkins, vous devez effectuer les étapes mentionnées ci-dessous :

Etape 1 : Créez un nouvel élément intitulé ‘LambdaTest – Intégration Selenium Maven Jenkins (Projet Pipeline)’ de type ‘Pipeline’.

Etape 2 : Dans la définition de Pipeline, collez le contenu de Jenkinsfile comme indiqué ci-dessous. Cliquez sur appliquer et enregistrer.

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 { agent tout outils { maven ‘MAVEN_3.6.3’ jdk ‘JDK_1.8.0_251’ } stages { stage(‘Run Tests’) { environnement { PROJECT_DIR_1 = « C :\Users\\Lenovo\\IdeaProjects\Maven_Jenkins » PROJECT_DIR_2 = « C:\Users\\Lenovo\\IdeaProjects\Maven_Jenkins_2 » } parallel { stage(‘Test Scenario 1’) { agent { label « Slave_1 » } steps { echo ‘maven clean’ bat ‘ mvn -f %PROJECT_DIR_1%\\pom.xml clean install’ } post { success { publishHTML () } } } stage(‘Test Scenario 2’) { agent { label « Slave_2 » } steps { echo ‘maven clean’ bat ‘ mvn -f %PROJECT_DIR_2%\\pom.xml clean install’ } post { success { publishHTML () } } } } } } }

Étape 3 : Dans la section post-build, le plugin HTML Publisher est utilisé pour créer les rapports de test post-exécution pour les deux scénarios de test.

Pipeline Walkthrough

Étape 1 : Cette tâche Jenkins spécifique peut être exécutée sur n’importe quel agent. La section avec la directive tools contient tous les outils qui doivent être installés automatiquement. Les mêmes sont ensuite également ajoutés à la variable d’environnement PATH.

1 2 3 4 5 6

pipeline { agent tout outils { maven ‘MAVEN_3.6.3’ jdk ‘JDK_1.8.0_251’ }

Sur la machine où seront exécutés les tests, le JDK 1.8.0_251 et Maven 3.6.3 sont installés. Les alias maven et jdk pointent vers les versions respectives de Maven et du JDK.

Etape 2 : La directive environment est utilisée pour définir les variables d’environnement PROJECT_DIR_1 et PROJECT_DIR_2 qui pointent vers l’emplacement où sont présents les projets Java. Ces variables d’environnement peuvent être utilisées pour toutes les étapes ou des étapes spécifiques à une étape puisqu’elles sont définies dans l’étape principale ‘Run Tests.’

1 2 3 4 5 6

stages { stage(‘Run Tests’) { environnement { PROJECT_DIR_1 = « C :\Users\\\Lenovo\\IdeaProjects\Maven_Jenkins » PROJECT_DIR_2 = « C:\Users\\Lenovo\\IdeaProjects\Maven_Jenkins_2 » }

Étape 3 : La directive parallèle dans Jenkins est utilisée pour exécuter les étapes du Pipeline en parallèle. Dans notre cas, le Pipeline de Jenkins se compose de deux étapes – le scénario de test 1 et le scénario de test 2.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

stages { stage(‘Run Tests’) { environnement { PROJECT_DIR_1 = « C :\Users\\Lenovo\\IdeaProjects\Maven_Jenkins » PROJECT_DIR_2 = « C:\Users\\Lenovo\\IdeaProjects\Maven_Jenkins_2 » } parallel { stage(‘Test Scenario 1’) { ………………………………….. ………………………………….. } stage(‘Test Scenario 2’) { ………………………………….. ………………………………….. } } } }

Étape 4 : Les actions effectuées dans les deux étapes sont exactement similaires, sauf qu’elles sont effectuées sur des projets différents. L’étape ‘Test Scenario 1‘ est exécutée sur le nœud ‘Slave_1‘ et l’étape ‘Test Scenario 2‘ est exécutée sur le nœud ‘Slave_2‘.

1 2 3 4 5 6 7 8 9 10 11

parallel { stage(‘Test Scenario 1’) { agent { label « Slave_1 » } …………. …………. stage(‘Test Scenario 2’) { agent { label « Slave_2 » }

Dans le cas où vous avez l’intention d’exécuter le pipeline sur n’importe quel agent, vous pouvez sauter l’utilisation d’un nom d’agent particulier dans ces étapes. Vous pouvez vous référer à notre blog What is Jenkins pour comprendre la création de nœuds dans Jenkins.

Dans notre cas, nous avons créé deux nœuds (Slave_1 et Slave_2) et les avons mis en ligne avant d’exécuter les tests.

Étape 5 : Dans l’étape suivante, la construction est déclenchée. La commande mvn clean install est alors exécutée sur pom.xml qui est présent dans le répertoire du projet. Nous utilisons une machine Windows pour l’exécution donc nous avons utilisé la commande bat (ou batch) pour déclencher le build de Maven.

1 2 3 4

étapes { echo ‘maven clean’ bat ‘ mvn -f %PROJECT_DIR_1%\\\pom.xml clean install’ }

Étape 6 : L’action post-build est utilisée pour publier des rapports HTML pour les étapes respectives. Les actions sont ajoutées sous la directive ‘post’. Nous voulons invoquer la création du rapport de test seulement si la construction est réussie. Par conséquent, les actions sont sous la directive ‘success’.

Comme on le voit dans la démonstration utilisant le projet FreeStyle, reportDir est défini à l’emplacement où les rapports surefire sont générés (c’est-à-dire ${project_dir}/target/surefire-reports). Le champ reportFiles est défini sur index.html (c’est-à-dire ${project_dir}/target/surefire-reports/index.html).

1 2 3 4 5 6 7 8 9 10 11 12 13

post { success { publishHTML () } }

Une fois que le pipeline est ajouté à Jenkinsfile, cliquez sur ‘Build Now’ pour lancer le processus de construction.

Vous pouvez survoler n’importe quelle étape et cliquer sur ‘Logs’ pour avoir un aperçu de la progression de l’exécution de cette étape particulière. Comme on le voit dans l’instantané de Stage, les deux étapes sont exécutées en parallèle.

Comme nous utilisons des étapes parallèles avec un Pipeline déclaratif dans Jenkins, les cas de test respectifs sont exécutés en parallèle sur la grille Selenium basée sur le cloud sur LambdaTest. Comme indiqué ci-dessous, notre plan sur LambdaTest prend en charge un maximum de cinq tests à exécuter en parallèle.

Comme indiqué ci-dessous, les tests ont été exécutés avec succès.

Le temps d’exécution total était d’environ 6 minutes. Vous pouvez survoler n’importe quelle étape pour afficher les journaux associés à cette étape.

Comme on le voit dans les journaux tronqués, il est évident que les étapes des deux étapes s’exécutaient en parallèle :

Voici la capture d’écran des rapports HTML qui sont générés dans le cadre de l’action post-build :

Wrapping up

source

L’exécution de tests Selenium dans Jenkins donne la flexibilité d’exécuter des tests chaque fois qu’il y a un changement de logiciel, et ces changements doivent être testés contre différentes combinaisons d’entrée. Maven est utilisé dans les projets Java, car il facilite la tâche de gestion des dépendances via le fichier pom.xml.

Les projets Freestyle dans Jenkins devraient être utilisés pour les projets qui ne sont pas d’une grande complexité. Jenkins Pipeline doit être utilisé lorsque vous souhaitez définir le pipeline de déploiement en tant que code. La directive parallèle dans Jenkins Pipeline doit être utilisée pour tirer parti de l’exécution parallèle des Stages dans Jenkins. Jenkins Pipeline peut être intégré à une grille Selenium basée sur le cloud comme LambdaTest, qui vous permet également d’intégrer Maven et Jenkins à Selenium de manière plus efficace.

Nous espérons qu’en suivant ce tutoriel, vous pourrez facilement intégrer Maven et Jenkins avec Selenium. Merci de votre lecture!

Himanshu Sheth

Avec plus de 7 ans d’expérience dans l’automatisation des tests, BDD, TDD, Himanshu Sheth travaille comme ingénieur d’automatisation avec LambdaTest. Il est également un blogueur avide.

.