Articles

¿Cómo integrar Jenkins y Maven con Selenium?

On septiembre 23, 2021 by

Este artículo forma parte de nuestro Content Hub. Para obtener más recursos en profundidad, echa un vistazo a nuestro centro de contenido en Jenkins Tutorial.

Jenkins es una de las herramientas populares para la integración continua, gestión de la construcción, y las pruebas de automatización. Maven es una popular herramienta de automatización de la construcción que se utiliza ampliamente para los proyectos de Java. La combinación de Selenium, Maven, la integración de Jenkins es el pináculo de la integración continua y el despliegue.

Como parte de las pruebas de automatización, estamos seguros de que su equipo viene con numerosos scripts de automatización de pruebas de Selenium cada dos días. Como Selenium en sí mismo no se utiliza para la integración continua, Selenium, Maven y la integración de Jenkins se aprovechan para la gestión de la construcción y la integración continua. En este artículo, vemos el uso de Maven y Jenkins con Selenium.

Un rápido resumen de la entrada del blog está por debajo:

Overview Of Selenium, Maven, & Jenkins

Maven es una popular herramienta de automatización de la construcción que se utiliza principalmente para proyectos Java. La ventaja de utilizar Maven es que las librerías Java y los plugins se descargan de forma dinámica desde el repositorio central de Maven 2.

Las dependencias y otra información esencial relacionada con la construcción se almacenan en un archivo pom.xml del proyecto. Una vez descargadas, las dependencias se almacenan en una caché local (repositorio .M2), y la misma se utiliza para la generación de la construcción. Esto simplifica el proceso de construcción, ya que cualquier nueva dependencia del proyecto tiene que ser añadido sólo en pom.xml, es decir, no se requiere la descarga manual y los paquetes de instalación.

Selenium es un marco de automatización de pruebas ampliamente utilizado para validar las aplicaciones web a través de diferentes combinaciones de navegadores, plataformas y dispositivos (o emuladores). Puede consultar nuestros blogs sobre cómo se puede utilizar Selenium Grid para las pruebas automatizadas del navegador.

Jenkins es una herramienta CI/CD de código abierto que ayuda en la automatización de las actividades relacionadas con la construcción, la prueba y el despliegue. Jenkins tiene un extenso ecosistema de plugins, es de código abierto, y una comunidad apasionada – factores que se pueden atribuir a las características de Jenkins.

En este blog de Maven y Jenkins con Selenium, estaríamos utilizando TestNG, que es un marco de prueba popular que se inspira en JUnit. Es ampliamente utilizado para las áreas de prueba como las pruebas funcionales, pruebas de extremo a extremo, y más.

Este es el conjunto de herramientas que estaríamos utilizando en la demostración:

  • Maven – Herramienta de gestión de proyectos en Java
  • TestNG – Popular marco de automatización de pruebas
  • Selenium WebDriver – Biblioteca utilizada principalmente para la automatización de las interacciones del navegador
  • Jenkins – Herramienta para la integración continua (CI) y el despliegue continuo (CD)

Este es el flujo general de información cuando Selenium, Maven, y Jenkins están integrados:

  • Una vez que el desarrollador empuja el código en el repositorio (e.g., GitHub), se dispara una compilación de Jenkins.
  • Maven descarga los paquetes de librerías dependientes &y comienza a realizar la compilación. La información relacionada con el conjunto de pruebas está disponible en testing.xml, y lo mismo se utiliza en pom.xml.
  • Se establece un objetivo de construcción (por ejemplo, instalar) para ejecutar las pruebas automatizadas. Lo mismo se logra a través del maven-surefire-plugin.
  • El maven-surefire-plugin le dice a TestNG que ejecute las pruebas que están bajo la anotación @Test.
  • Dependiendo del AUT (aplicación bajo prueba) y del navegador (&combinación de SO) en el que se realicen las pruebas cruzadas de navegador, el Selenium WebDriver invoca la instancia de navegador correspondiente y ejecuta las mismas pruebas de automatización.
  • Los resultados de las pruebas se publican en Informes HTML, ya que se utiliza el plugin HTML Publisher para la generación de informes.
  • Incluso si un solo caso de prueba ha fallado, la prueba completa se marca con el estado ‘Failed.

Ventajas del uso de Maven & Jenkins con Selenium

Antes de demostrar el uso de la integración Selenium Maven Jenkins, vamos a echar un vistazo a las principales ventajas de usar Maven y Jenkins con Selenium:

  • Cada vez que se realiza un cambio en la implementación, los cambios se despliegan en el entorno de pruebas. Las pruebas de automatización se realizan de forma continua, y los desarrolladores se mantienen informados sobre los resultados de la etapa de construcción y de prueba.
  • Los conjuntos de pruebas que comprenden muchos escenarios de prueba (o combinaciones de pruebas) podrían tener una duración más larga para las pruebas de automatización. En estos casos se puede programar una ejecución de construcción nocturna para construir y ejecutar en el servidor Jenkins.
  • Como Maven utiliza pom.xml, reduce la dependencia general de la descarga manual de archivos jar. Además, el tipo de ‘Proyecto Maven’ en Jenkins ayuda a comenzar con Selenium Maven, la integración de Jenkins con unos pocos ajustes de configuración.
  • La configuración de integración de Selenium Maven Jenkins es adecuada para los equipos de desarrollo y pruebas distribuidos en diferentes ubicaciones geográficas.

Requisitos para el proyecto Jenkins Selenium

Para la demostración de Maven y Jenkins con Selenium, los siguientes softwares deben estar instalados (o disponibles) en la máquina desde donde se disparan las pruebas:

  • Eclipse IDE o IntelliJ IDEA (Maven viene por defecto en estos dos IDEs)
  • Jenkins en formato .war
  • Cromo WebDriver que coincida con la versión del navegador Chrome de tu máquina
  • Microsoft Edge Driver
  • Cuenta en LambdaTest (ya que las pruebas se ejecutan en el Selenium Grid basado en la nube de LambdaTest)

Demostración de la integración Selenium Maven Jenkins

Para ahorrar tiempo, no vamos a ver cada paso de la creación de un proyecto Maven. En caso de que quieras un resumen rápido de Maven con Selenium, puedes consultar este tutorial de Maven para la automatización de pruebas con Selenium. Los pasos utilizados para la creación de un proyecto Maven en IntelliJ IDEA son similares a los utilizados en la creación de un proyecto Maven en Eclipse IDE.

Suite de Pruebas – 1

Escenario de Pruebas – 1 (Chrome en Windows 10)

  1. Navega a esta URL- https://lambdatest.github.io/sample-todo-app/.
  2. Elige las dos primeras casillas de verificación.
  3. Introduce ‘Happy Testing at LambdaTest’ en el cuadro de texto de abajo con el siguiente id = sampletodotext.
  4. Ahora, haz clic en el botón Add y verifica si el texto se ha añadido o no.

Escenario de prueba – 2 (Pruebas en 4 combinaciones diferentes de navegador y sistema operativo)

  1. Navegue a esta URL- https://www.google.com.
  2. Busque «LambdaTest».
  3. Haga clic en el primer resultado de la prueba.
  4. Ahora, lanza un Assert si el título de la página no coincide con el título esperado.

Implementación

Hay que añadir las dependencias y plugins adecuados en el pom.xml del proyecto. Estos son los paquetes (o jars) clave que forman parte del pom.xml:

  • Selenium 4 (Alpha)
  • TestNG framework (versión 6.9.10)
  • Maven Surefire plugin for execution of test suite which is a part of testng.xml
  • Plugin Maven Surefire Report para generar el informe de resultados de las pruebas en formato HTML

Si se pretende añadir algún nuevo plugin o jar al pom.xml, busque el mismo en el repositorio de Maven y añada la dependencia/plugin correspondiente en la sección pertinente.

El conjunto de pruebas contiene dos casos de prueba, concretamente test_Selenium4_ToDoApp() & test_Selenium4_GoogleSearch(). Como se muestra a continuación, la implementación de estos casos de prueba se almacena en archivos separados, a saber, CrossBrowserTest.java y GoogleSearchTest.java, y ambos son una parte del paquete org.selenium4.

El escenario de prueba test_Selenium4_ToDoApp() está destinado a ser ejecutado en Chrome (última versión) para Windows 10. Por otro lado, el escenario de prueba test_Selenium4_GoogleSearch() tiene que ser ejecutado en 4 combinaciones diferentes de navegadores y sistemas operativos, es decir, Chrome (última versión) en Windows 10, Edge (84.0) en Windows 10, Chrome (última versión) en macOS Mojave, y Firefox (última versión) en OS X Mavericks.

Las entradas en testng.xml para test_Selenium4_GoogleSearch() se han alineado de acuerdo con las capacidades del navegador generadas por el generador de capacidades de LambdaTest. A continuación se muestran las capacidades de muestra generadas para Chrome (más reciente) & Combinación de Windows 10:

En la implementación, utilizaríamos listeners de TestNG en Selenium WebDriver para las pruebas de automatización. A nivel de suite, definimos los nombres de las clases para implementar los listeners en el archivo xml de TestNG. La anotación @listeners en TestNG se utiliza para añadir la clase org.selenium4.GoogleSearchTest.

Como se muestra a continuación, el nombre de la prueba ‘Google Search Test – 1’ tomará parámetros de entrada que especifican el navegador, la versión, la plataforma y la resolución de visualización. Estos valores se pasarían al método de prueba como argumentos utilizando anotaciones parametrizadas (es decir, @org.testng.annotations.Parameters(value={«browser», «version», «platform», «resolution»}).

1
2
3
4
5
6
7
8
9
10
11
12
13
<escuchadores>
<escuchadores class-name=»org.selenium4.GoogleSearchTest»/>
<listeners>
<test name=»Google Search Test – 1″>
<parameter name=»browser» value=»Chrome»/>
<parameter name=»version» value=»latest»/>
<parameter name=»platform» value=»Windows 10″/>
<parameter name=»resolution» value=»1600×1200″/>
<classes>
<class name=»org.selenium4.GoogleSearchTest»/>
</classes>
</test>

CrossBrowserTest.java (Implementación del escenario de prueba – 1)

GoogleSearchTest.java (Implementación del Escenario de Prueba – 2)

Código de avance

Paso 1 – Se importan los paquetes necesarios antes de iniciar la implementación real. Dado que el marco TestNG se utiliza para las pruebas; por lo tanto, sus paquetes también se importan antes de que sus anotaciones puedan ser utilizadas.

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.*;

Paso 2 – El IExecutionListener se utiliza para supervisar el inicio y el final del conjunto de pruebas, ya que el escenario de pruebas se ejecutaría en diferentes combinaciones de entrada que se pasan a través del archivo xml TestNG.

El IExecutionListener contiene dos métodos – onExecutionStart() y onExecutionFinish(). onExecutionStart() se invoca antes del inicio de la prueba y onExecutionFinish() se invoca una vez que las pruebas/suites de prueba han terminado la ejecución.

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»);
}

Paso 3 – El método implementado bajo la anotación @BeforeTest se ejecutará antes de que se ejecute cualquier método de prueba perteneciente a la clase bajo esa etiqueta. Como estamos utilizando pruebas parametrizadas con TestNG, la anotación @Parameters(value={«browser», «version», «platform», «resolution»}) se añade al método de prueba.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
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 {
…………………………
…………………………
}

Estos parámetros se pasarían valores desde testng.xml, parámetro de ejemplo que se muestra a continuación:

Paso 4 – El método testSetUp es un método parametrizado que toma iterativamente los parámetros de prueba desde TestNG.xml hasta que se encuentra el final del conjunto de pruebas.

Como las pruebas se ejecutan en la nube Selenium Grid en LambdaTest, las credenciales consisten en un nombre de usuario &un token de acceso que se puede utilizar para acceder a la LambdaTest Grid – @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 {3567>

driver = new RemoteWebDriver(new URL(«http://» + nombre_de_usuario + «:» + clave_de_acceso + «@hub.lambdatest.com/wd/hub»), capabilities);
} catch (MalformedURLException e) {
System.out.println(«Invalid grid URL»);
}
System.out.println(«Sesión iniciada»);

La API RemoteWebDrive utiliza la URL remota y las capacidades del navegador que se generan mediante el generador de capacidades de LambdaTest y se pasan al método en forma de parámetros de entrada.

1
2
3
4
try {3567>

driver = new RemoteWebDriver(new URL(«http://» + username + «:» + access_key + «@hub.lambdatest.com/wd/hub»), capabilities);
}
catch (MalformedURLException e)

Paso 5 – El método de prueba se implementa bajo la anotación @Test. Los métodos de Selenium apropiados (findElement, sendKeys, submit, y más) se utilizan para localizar el elemento web y realizar las acciones apropiadas sobre el mismo.

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 {
/* Introduce el término de búsqueda en el cuadro de búsqueda de Google */
search_box = driver.findElement(By.xpath(«//input»));
search_box.sendKeys(search_string);
search_box.submit();
……………………………………
……………………………………
}
……………………………………
……………………………………
}

Paso 6 – Bloquear los retardos no es una buena práctica de programación, pero hemos añadido algunos retardos para observar la salida.

1
2
3
4
5
6
7
WebElement lt_link = driver.findElement(By.xpath(«//h3»));
lt_link.click();
/* No es una buena práctica de programación, se añade para la demostración */
Thread.sleep(5000);
……………………………………
……………………………………

Paso 7 – El método que se implementa bajo la anotación @AfterTest libera los recursos asignados por el WebDriver correspondiente instanciado.

1
2
3
4

¡

5
6
7
@AfterClass
public void tearDown() {
if (driver != null) {
((JavascriptExecutor) driver).executeScript(«lambda-status=» + status);
driver.quit();
}
}

Secuencia de Pruebas – 2

Escenario de Pruebas – 1 (Chrome en Windows 10)

  1. Navega a la URL https://lambdatest.com
  2. Comprueba la Página Title
  3. Comparar el título de la página con el título esperado
  4. Asegurar si los títulos no coinciden

Implementación

Es la misma que se utiliza para el Test Suite-.1, excepto por el artifactId y groupID.

CrossBrowserTest.java

Para la demostración de Maven y Jenkins con Selenium, estaríamos ejecutando estas dos suites de pruebas en paralelo usando el proyecto FreeStyle y Jenkins Pipeline.

¡Woo-hoo! ¡Gracias por suscribirte al boletín semanal de LambdaTest!

Configuración de Jenkins para el proyecto Jenkins Selenium

Antes de crear un nuevo trabajo en Jenkins que construya el proyecto mencionado anteriormente, tenemos que configurar el entorno de Jenkins.

Paso 1: La ruta de instalación de JDK tiene que ser añadida a la variable de entorno del sistema. Esto también es necesario para JRE (Java Runtime Environment).

Paso 2: Descargar Jenkins en formato .war e inicie Jenkins ejecutando el siguiente comando en el 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

En lugar del 8080 (número de puerto por defecto utilizado por Jenkins), iniciamos el servicio Jenkins en el puerto 9090.

Paso 3: Visita localhost:9090 en el navegador web para empezar a usar Jenkins.

Crea un nuevo usuario (con privilegios de administrador). Inicie sesión utilizando ese nombre de usuario para continuar utilizando Jenkins.

Paso 4: Como el proyecto está utilizando Maven y Jenkins con Selenium, la configuración global y las rutas para Java & Maven tiene que ser configurado en Jenkins. Para configurar estos ajustes, navegue a ‘Configure System’ en la sección ‘System Configuration’.

En el elemento titulado ‘Global properties’, añade las siguientes variables de entorno:

1
2
JAVA_HOME – <Lugar donde está instalado el JDK>
MAVEN_HOME – <Lugar donde está instalado Maven>

En nuestro caso las entradas son las siguientes:

1
2
JAVA_HOME – C:\N-Archivos de Programa\NJava\jdk1.8.0_251
MAVEN_HOME – C:\apache-maven\apache-maven-3.6.3\

Haga clic en Aplicar y Guardar.

La adición de estas variables de entorno en la Configuración del sistema hace que los ajustes sean públicos (es decir.e. se puede utilizar para el proyecto Jenkins FreeStyle y el proyecto Jenkins Pipeline).

Paso 5: El plugin HTML Publisher debe instalarse antes de que se pueda realizar la acción posterior a la construcción de las pruebas. Lo mismo se puede hacer navegando a ‘Manage Plugins’ y buscando ‘HTML Publisher Plugin’ en la pestaña ‘Available’. Haga clic en ‘Install’ para instalar el plugin.

Nota: Para las pruebas entre navegadores, se recomienda utilizar Jenkins en el formato .war ya que las pruebas se ejecutan en el modo no headless sólo cuando Jenkins se utiliza en el formato .war.

Integración de Selenium Maven Jenkins utilizando un proyecto FreeStyle

Para crear un proyecto FreeStyle que utilice la integración de Selenium Maven Jenkins como demostración, realice los siguientes pasos en la UI de Jenkins (i.e. localhost:9090/)

(Nota – El número de puerto variará en función del puerto utilizado por Jenkins)

Paso 1: En el ‘Jenkins UI’, haga clic en ‘New Item’.

Paso 2: Introduzca el nombre del trabajo como ‘LambdaTest – Selenium Maven Jenkins integration (Maven Project)’ y seleccione ‘FreeStyle’ project.

Jenkins también proporciona una opción para crear un proyecto ‘Maven’ donde los ajustes de configuración necesarios para establecer el proyecto son mínimos. Sin embargo, para esta demostración, hemos utilizado un proyecto ‘FreeStyle’.

Paso 3: Ir a la opción ‘Build’ ? ‘Invoke top-level Maven targets’. La versión de Maven debe apuntar a la versión de Maven instalada en la máquina. En nuestro caso, es Maven 3.6.3.

Paso 4: Pulsar en ‘Advanced’ para configurar los Objetivos, establecer la ubicación de los archivos POM para los dos test suites. En nuestro caso, las ubicaciones del proyecto son las siguientes:

Como queremos realizar construcciones paralelas, utilizamos la siguiente opción con el comando mvn:

1
mvn -T 4 clean install

Este comando realizará construcciones con 4 hilos. En la sección «Objetivos», debe introducir -T 4 clean install. El mismo objetivo se establece para las construcciones de Maven para ambos proyectos. En ‘POM’, dar la ubicación absoluta de pom.xml

(es decir, Build 1 – C:\sers\Lenovo\IdeaProjects\Maven_Jenkins\pom.xml

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

Paso 5: La ‘acción post-Build’ es publicar informes HTML que den información sobre el escenario general de las pruebas (es decir, número de pruebas pasadas/falladas/saltadas, etc.). Seleccione ‘Publish HTML Reports’ en ‘Add post-build action’.

Paso 6: El plugin Maven Surefire Report analiza los archivos TEST-*.xml generados bajo ${project_dir}/target/surefire-reports y los renderiza usando DOXIA. En «Directorio HTML a archivar», introduzca la ruta absoluta de la ubicación que contiene los informes Surefire.

Para el conjunto de pruebas 1:

1
2
3
Directorio HTML para archivar – ${project_dir_1}/target/surefire-reports
Página(s) de índice – index.html
Título del informe – Informe del escenario de pruebas 1

Para el conjunto de pruebas 2:

1
2
3
Directorio HTML para archivar – ${project_dir_2}/target/surefire-reports
Página(s) de índice – index.html
Título del informe – Informe del escenario de prueba 2

Paso 7: El proyecto ya está listo para ser construido. Haga clic en la opción ‘Build Now’ para activar la construcción.

Paso 8: Haga clic en ‘Console Output’ para ver el progreso de las etapas de construcción, prueba e informe.

Paso 9: Como se ve en los ‘registros de la consola; las pruebas se ejecutan con éxito – cinco casos de prueba como parte del primer conjunto de pruebas y un caso de prueba como parte del segundo conjunto de pruebas.

Aquí están las capturas de pantalla de los informes HTML que se generan para los dos conjuntos de pruebas por el HTML Publisher Plugin.

Informe para el escenario de pruebas – 1

Informe para el escenario de pruebas – 2

Integración de Selenium Maven Jenkins utilizando el Pipeline de Jenkins

En esta sección de demostración de Maven y Jenkins con Selenium, estaríamos utilizando el Pipeline de Jenkins que utiliza el Lenguaje Específico de Dominio (DSL) para realizar el Pipeline como Código.

La definición de un Pipeline de Jenkins se escribe normalmente en un archivo llamado Jenkinsfile. Este archivo contendría los pasos necesarios para ejecutar el Pipeline de Jenkins. Para una rápida recapitulación sobre el Jenkins Pipeline declarativo, puedes consultar este tutorial de Jenkins Pipeline.

Para integrar Maven y Selenium con el Jenkins Pipeline, tienes que realizar los pasos que se mencionan a continuación:

Paso 1: Crear un nuevo elemento titulado ‘LambdaTest – Selenium Maven Jenkins integration (Pipeline Project)’ de tipo ‘Pipeline’.

Paso 2: En la definición del Pipeline, pegue el contenido de Jenkinsfile como se muestra a continuación. Haga clic en Aplicar y Guardar.

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 any
tools {
maven ‘MAVEN_3.6.3’
jdk ‘JDK_1.8.0_251’
}
stages {
stage(‘Run Tests’) {
environment {
PROJECT_DIR_1 = «C:\\NUsers\NLenovo\NIdeaProjects\NMaven_Jenkins»
PROJECT_DIR_2 = «C:\NUsers\NLenovo\NIdeaProjects\NMaven_Jenkins_2»
}
parallel {
stage(‘Test Scenario 1’) {
agent {
label «Slave_1»
}
pasos {
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 ()
}
}
}
}
}
}
}

Paso 3: En la sección de post-construcción, se utiliza el plugin HTML Publisher para crear los informes de prueba posteriores a la ejecución de los dos escenarios de prueba.

Paseo por la línea de producción

Paso 1: Este trabajo específico de Jenkins puede ejecutarse en cualquier Agente. La sección con la directiva tools contiene todas las herramientas que deben instalarse automáticamente. Lo mismo se añade a la variable de entorno PATH.

1
2
3
4
5
6
pipeline {
agent any
tools {
maven ‘MAVEN_3.6.3’
jdk ‘JDK_1.8.0_251’
}

En la máquina donde se ejecutarán las pruebas, están instalados JDK 1.8.0_251 y Maven 3.6.3. Los alias maven y jdk apuntan a las respectivas versiones de Maven y JDK.

Paso 2: La directiva de entorno se utiliza para definir las variables de entorno PROYECTO_DIR_1 y PROYECTO_DIR_2 que apuntan a la ubicación donde están los proyectos Java. Estas variables de entorno se pueden utilizar para todos los pasos o para pasos específicos de la etapa, ya que se definen en la etapa principal ‘Ejecutar pruebas.’

1
2
3
4
5
6
etapas {
etapa(‘Ejecutar pruebas’) {
entorno {
PROJECT_DIR_1 = «C:\\NUsers\NLenovo\NIdeaProjects\NMaven_Jenkins»
PROJECT_DIR_2 = «C:\NUsers\NLenovo\NIdeaProjects\NMaven_Jenkins_2»
}

Paso 3: La directiva parallel en Jenkins se utiliza para ejecutar las etapas del Pipeline en paralelo. En nuestro caso, el Pipeline de Jenkins consta de dos etapas – Escenario de prueba 1 y Escenario de prueba 2.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
stage(‘Run Tests’) {
environment {
PROJECT_DIR_1 = «C:\\NUsers\NLenovo\NIdeaProjects\NMaven_Jenkins»
PROJECT_DIR_2 = «C:\NUsers\NLenovo\NIdeaProjects\NMaven_Jenkins_2»
}
parallel {
stage(‘Test Scenario 1’) {
…………………………………..
…………………………………..
}
stage(‘Test Scenario 2’) {
…………………………………..
…………………………………..
}
}
}
}

Paso 4: Las acciones realizadas en ambas etapas son exactamente similares excepto que se realizan en proyectos diferentes. La etapa ‘Test Scenario 1‘ se ejecuta en el nodo ‘Slave_1‘ y la etapa ‘Test Scenario 2‘ se ejecuta en el nodo ‘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»
}

En caso de que pretenda ejecutar el pipeline en cualquier agente, puede omitir el uso de cualquier nombre de agente en particular en estas etapas. Puedes consultar nuestro blog What is Jenkins para entender la creación de Nodos en Jenkins.

En nuestro caso, creamos dos Nodos (Slave_1 y Slave_2) y los pusimos en línea antes de ejecutar las pruebas.

Paso 5: En el siguiente paso, se activa la construcción. El comando mvn clean install se ejecuta sobre el pom.xml que está presente en el directorio del proyecto. Estamos utilizando una máquina Windows para la ejecución por lo tanto hemos utilizado el comando bat (o batch) para desencadenar la construcción de Maven.

1
2
3
4
pasos {
echo ‘maven clean’
bat ‘ mvn -f %PROJECT_DIR_1%\pom.xml clean install’
}

Paso 6: La acción post-construcción se utiliza para la publicación de informes HTML para las respectivas etapas. Las acciones se añaden bajo la directiva ‘post’. Queremos invocar la creación del informe de prueba sólo si la construcción es exitosa. Por lo tanto, las acciones están bajo la directiva de éxito.

Como se ve en la demostración utilizando el proyecto FreeStyle, reportDir se establece en la ubicación donde se generan los informes surefire (es decir, ${project_dir}/target/surefire-reports). El campo reportFiles se establece en index.html (es decir, ${project_dir}/target/surefire-reports/index.html).

1
2
3
4
5
6
7
8
9
10
11
12
13
post {
success {
publishHTML ()
}
}

Una vez que la tubería se añade a Jenkinsfile, haga clic en ‘Build Now’ para iniciar el proceso de construcción.

Puede desplazarse a cualquier etapa y hacer clic en ‘Logs’ para echar un vistazo al progreso de ejecución de esa etapa en particular. Como se ve en la instantánea de la etapa, las dos etapas se ejecutan en paralelo.

Como estamos utilizando etapas paralelas con Pipeline declarativo en Jenkins, los respectivos casos de prueba se ejecutan en paralelo en la red Selenium basada en la nube en LambdaTest. Como se muestra a continuación, nuestro plan en LambdaTest soporta un máximo de cinco pruebas que se ejecutan en paralelo.

Como se muestra a continuación, las pruebas se han ejecutado con éxito.

El tiempo total de ejecución fue de aproximadamente 6 minutos. Puede pasar el cursor sobre cualquier etapa para ver los registros asociados a esa etapa.

Como se ve en los registros truncados, es evidente que los pasos de las dos etapas se estaban ejecutando en Paralelo:

Aquí está la captura de pantalla de los informes HTML que se generan como parte de la acción post-construcción:

Envolviendo

Fuente

Ejecutar pruebas de Selenium en Jenkins da la flexibilidad de ejecutar pruebas cada vez que hay un cambio en el software, y esos cambios tienen que ser probados contra diferentes combinaciones de entrada. Maven se utiliza en proyectos Java, ya que facilita la tarea de gestionar las dependencias a través del archivo pom.xml.

Los proyectos de estilo libre en Jenkins deben utilizarse para proyectos que no sean de alta complejidad. Jenkins Pipeline se debe utilizar cuando se quiere definir el Pipeline de despliegue como código. La directiva paralela en Jenkins Pipeline debe utilizarse para aprovechar la ejecución paralela de las Etapas en Jenkins. Jenkins Pipeline se puede integrar con un Selenium Grid basado en la nube como LambdaTest, que también permite integrar Maven y Jenkins con Selenium de una manera más eficiente.

Esperamos que siguiendo este tutorial, puedas integrar fácilmente Maven y Jenkins con Selenium. Gracias por leer!

Himanshu Sheth

Con más de 7 años de experiencia en automatización de pruebas, BDD, TDD, Himanshu Sheth trabaja como ingeniero de automatización con LambdaTest. También es un ávido bloguero.

Escrito por

Deja una respuesta

Tu dirección de correo electrónico no será publicada.