Selenium WebDriver en un Ambiente de Pruebas Continuas

Selenium automatiza los navegadores. ¡Eso es todo! Lo que hagas con ese poder depende de ti. Principalmente, es para la automatización de aplicaciones web con fines de pruebas, pero ciertamente no se limita a eso. Las tareas aburridas de administración basadas en web pueden (¡y deben!) ser automatizadas. Una definición muy concreta y directa, pero vamos a ampliar un poco más la definición.

El texto anterior es la introducción en la página principal de SeleniumHQ [1]. Selenium es un conjunto de herramientas de código abierto que nos ayuda a automatizar acciones que un usuario puede realizar sobre aplicaciones web. Cada herramienta dentro de este conjunto tiene un enfoque diferente para apoyar el proceso de automatización de pruebas.

Los cuatro componentes de Selenium son:

1. Selenium IDE: es un entorno de desarrollo integrado para scripts de Selenium. Se implementa como una extensión de Firefox y permite grabar, editar y depurar pruebas. Este IDE incluye todo el Selenium Core, que permite grabar y reproducir de forma fácil las pruebas en el entorno real en el cual se ejecutarán. Se recomienda su uso para prototipos de pruebas, debido a que no es capaz de generar ciclos ni condiciones.

2. Selenium RC (Remote Control): es una herramienta para automatizar pruebas de interfaz de usuario (UI) de aplicaciones web. Consta de dos componentes: a) un servidor que actúa como proxy para controlar e interactuar con un navegador web. b) bibliotecas para crear programas para el servidor usando una amplia gama de lenguajes de programación. Fue la herramienta original de Selenium para pruebas web pero a partir de la versión 2 fue integrado con WebDriver y se prefiere usar este último.

3. Selenium WebDriver: también es una herramienta para automatizar pruebas UI de aplicaciones web pero implementa un enfoque más moderno y estable que Selenium RC. WebDriver, a diferencia de RC no utiliza un middleware sino que controla el navegador comunicándose directamente con él.

4. Selenium Grid: se especializan en ejecutar múltiples pruebas a través de diferentes navegadores, sistemas operativo y máquinas. Puede conectarse con Selenium Remote especificando el navegador, la versión del navegador y el sistema operativo que desee. Hay dos elementos principales: hub y nodos.

En este artículo nos enfocaremos en WebDriver. Como ya comentamos, es un framework de automatización web que permite ejecutar casos de prueba sobre distintos navegadores. Debido a que es posible utilizar lenguajes de programación para la creación de scripts de pruebas, podemos tener estructuras de control como condiciones y bucles para controlar el comportamiento. Algunos de los lenguajes soportados son: Java, C#, Python, Ruby, PHP y JavaScript.

Arquitectura

A primera vista puede parecer que Selenium está manejando el navegador directamente desde nuestro código, sin embargo este proceso es un poco más complejo de lo que pareciera. La arquitectura de WebDriver está dividida en tres partes principales: lenguaje de vinculación, WebDriver API y drivers.

Para ver cómo es que interactúan las partes entre sí, digamos que se ha escrito el script de prueba usando Java (lenguaje de vinculación) para comunicarse con la API de WebDriver. El código generado va a emitir comandos a través del WebDriver wire protocol, el cual es un servicio REST capaz de interpretar dichos comandos. El driver es un ejecutable que básicamente escucha en un puerto de la máquina local cuando se ejecutan las pruebas y espera que los comandos entren. Una vez que los comandos son captados por el driver, estos son interpretados y ejecutados sobre el navegador.

Figura 1. Arquitectura WebDriver.

Ventajas y desventajas

La tabla 1 lista un comparativo de WebDriver contra otras herramientas que cumplen un propósito similar.

Tabla 1. Tabla comparativa

Continuous Testing con WebDriver

Continuous Testing (CT) es en realidad una metáfora para un mecanismo de retroalimentación continua que impulsa la entrega de software funcional. La retroalimentación automatizada en cada punto de control es un disparador automático para el siguiente proceso en la cadena de entrega si la retroalimentación es para avanzar. Si la retroalimentación no avanza, el proceso se detiene inmediatamente y se toman medidas correctivas. Las organizaciones de TI tradicionales pueden acortar el camino para implementar CT reutilizando y realineando las capacidades de automatización de pruebas existentes.

Si se cuenta con un proceso de integración continua, la automatización de pruebas de UI es relativamente sencilla ya que se puede llevar a cabo con Selenium WebDriver y una herramienta de CI como Jenkins. El único requisito es utilizar un framework de pruebas unitarias como lo es TestNG, JUnit, NUnit, PHPUnit, etc. La figura 2 muestra un mapeo entre herramientas a través de distintas actividades y disciplinas del ciclo de desarrollo de software.

Figura 2. Selenium WebDriver dentro del proceso de integración continua.

Ejemplo

A continuación, se presenta un ejemplo de cómo realizar pruebas dirigidas por datos (data driven testing) con el framework de pruebas unitarias TesNG. El ejercicio consistirá en probar el formulario de registro de usuario en la página Mercury Tours (http://newtours.demoaut.com). Todos los archivos y código usado para el ejercicio se encuentran disponibles en https://github.com/gsanchez-tiempodev/SoftwareGuruDemo

El caso de prueba que se ejecuta es el siguiente:

Descripción: Registrar usuario para la página Mercury Tours

Procedimiento:

1. Navegar a la página de Mercury Tours

2. Dar click en enlace REGISTER

3. Ingresar <First Name>

4. Ingresar <Last Name>

5. Ingresar <Phone>

6. Ingresar <Email>

7. Ingresar <Address>

8. Ingresar <City>

9. Ingresar <State>

10. Ingresar <Postal Code>

11. Seleccionar <Country>

12. Ingresar <User Name>

13. Ingresar <Password>

14. Ingresar <Confirm Password>

15. Dar Click en botón Submit

Resultado esperado:

Página con el mensaje: “Dear <First Name>, Thank you for registering. You may now sign-in using the user name and password you've just entered. Note: Your user name is <User Name>.“

Cómo podemos ver, necesitamos llenar una cantidad considerable de campos en el formulario de registro, por lo que será útil alimentar los datos de prueba desde una hoja de cálculo. Así que preparamos un archivo FlightRegisterData.xls con una hoja llamada RegisterUser que contenga los datos mostrados en la figura 3, cuyas columnas corresponden a los campos que requerimos introducir en la forma de registro.

Figura 3. Datos de Prueba.

Nuestra clase principal llamada RegisterUsers.java, es donde se llamarán todos los métodos del negocio y algunos métodos comunes.

Para extraer los datos de nuestro archivo de Excel, creamos un arreglo bidimensional de objetos (Object[][]) que guardará los valores del Excel. Para iniciar el método que nos ayudará a la recolección de los datos, utilizamos la anotación @DataProvider y le damos un nombre, en este caso lo llamamos UserRegistration. Dicho método se apoya en una utilería para leer datos de nuestra hoja de Excel y vaciarlos en el arreglo de objetos que regresamos como resultado.

Listado 1. Leer datos de prueba

Tenemos un método setUp con la anotación @BeforeTest que se encarga de abrir un navegador, ir al url de inicio y maximizar el navegador antes de que cualquiera de nuestras pruebas se ejecute. Al finalizar la ejecución queremos cerrar el navegador y terminar el driver que lo manipula, así que para ello creamos un método que llamamos tearDown y le ponemos la anotación @AfterTest. Antes de que se vuelva a llenar el formato de registro en cada iteración, deseamos que se le vuelva a dar click al enlace REGISTER; para realizar dicha acción creamos un método clickRegister con la anotación @BeforeMethod.

Listado 2. setUp, tearDown y clickRegister

El método contactInformation es el que se encarga de correr nuestra prueba y por ello lleva la anotación @Test. La firma de argumentos de este método es del tipo String … dataProvider,  la cual nos indica que acepta n número de argumentos (para este ejemplo serán 11). En este caso, vamos a estructurar los datos en 3 grupos: información de contacto (columnas 0 a 3), dirección de correo (columnas 4 a 8) e información de usuario (columnas 9 y 10).  Separamos los datos y nos apoyamos en los métodos addContactInfo, addMailingInfo y submitUserInfo. Finalmente, hacemos un assert para validar que la página de resultado contiene el nombre del usuario.

Listado 3. Método de prueba

La clase Common.java define métodos reutilizables de acciones que se pueden ejecutar sobre los objetos web tales como escribir en un text box, seleccionar un elemento de un combo box, navegar a la página web, etcétera. Estas acciones se logran por medio de métodos que implementa el driver de selenium. El listado 4 tiene un ejemplo. El contenido completo se puede ver en el repositorio.

Listado 4. Algunos métodos en Common.java

Por su parte, Business.java contiene los métodos que siguen reglas de negocio, como lo puede ser un login, un alta de usuarios, etc. Un ejemplo es el método addMailingInfo, el cual utiliza los métodos definidos en Common.java para realizar el llenado de la información de correo del usuario que se va a registrar.

Listado 5. addMailingInfo

Finalmente, en la figura 4 se muestran los resultados generados por TestNG al ejecutar nuestra prueba aplicando los distintos datos.

Figura 4. Resultados de ejecución generados por TestNG.

 

Referencias

1. SeleniumHQ. http://www.seleniumhq.org

2. “Introduction to Selenium”. Guru99. http://swgu.ru/sk

3. S. Honnamane & R. Bar. “Jumpstarting DevOps with Continuous Testing”. Cognizant 20-20 Insights. http://swgu.ru/sl