Ejecutando pruebas automatizadas móviles en paralelo usando Serenity BDD de manera sencilla

Uno de los mayores beneficios de usar Serenity BDD en la automatización de pruebas, es la capacidad que ofrece de generar una documentación robusta y detallada de los escenarios de prueba con cada ejecución de los mismos. Además, Serenity tiene una integración con Appium, una herramienta de automatización de pruebas móviles para aplicaciones nativas, híbridas y web mobile.

Cuando utilizamos ambas herramientas, en conjunto con otras como Cucumber, habilitan la construcción de pruebas móviles bien estructuradas y mantenibles, separando al QA de configuraciones adicionales y enfocándolo a lo que realmente le interesa: garantizar la construcción de una suite de pruebas capaz de detectar un error antes de que este salga a producción.

Paralelismo en la ejecución de pruebas

Debido a la gran variedad de dispositivos móviles que hay en el mercado, surge la necesidad de garantizar que la aplicación sea compatible con todos ellos y a los sistemas operativos que tienen. Por eso, ya no se trata sólo de soportar la ejecución de escenarios funcionales, sino también de garantizar la compatibilidad de la aplicación ante las miles de configuraciones de hardware y software que resultan de la variación de dispositivos. Ante esa realidad, se requiere una estrategia para paralelizar la ejecución de pruebas y un conjunto de dispositivos que la soporten.

Existen herramientas como Kobiton o pCloudy, que ofrecen un servicio equivalente a una granja de dispositivos físicos conectados a la nube, sobre los cuales se paga por consumo, lo que permite eliminar el esfuerzo de administrar un conjunto de dispositivos que se solicitan constantemente. También, dan la posibilidad de ejecutar pruebas en 2 o más dispositivos, sin embargo, la estrategia de paralelismo debe ser soportada por el proyecto de automatización.

Appium soporta la ejecución de pruebas en paralelo con sólo cambiar algunos capabilities e iniciar el appium server en diferentes puertos disponibles. Con Selenium Grid también es posible, basta con tener una infraestructura para la definición y configuración del Hub y los nodos.

¿Qué pasaría si no tengo la posibilidad de administrar mi propio appium server, o un hub? Por ejemplo, si se usa un proveedor como Kobiton para la ejecución de pruebas, no se tiene administración sobre el appium server y ninguna de sus versiones. Por tanto estrategias como la que ofrece Appium o Selenium Grid no son viables.

A continuación te enseñaré una manera sencilla de ejecutar pruebas en paralelo, con configuraciones mínimas usando el plugin de gradle: serenity-parallel-execution-plugin.

Este plugin, está diseñado para ejecutar pruebas construidas con Serenity BDD + Appium, lo que implica que no sólo es compatible con móviles, sino también con pruebas sobre aplicaciones de escritorio.

Configuración del plugin

Para la ejecución de pruebas, Serenity requiere un archivo de propiedades serenity.properties, el cual contiene una serie de parámetros que describen y configuran la forma en la que las pruebas serán corridas, como por ejemplo, el dispositivo físico y su sistema operativo.

Así, que lo primero que se requiere, es crear una carpeta (que para efectos del ejemplo llamaremos parallel) en la raíz del proyecto que contendrá todos los archivos de propiedades, uno por cada dispositivo donde se correrá la prueba. Se sugiere, nombrar cada archivo de propiedades con el nombre del dispositivo al que pertenece (ejm: iphone8.properties). Posterior a eso, se deben agregar las siguientes líneas al archivo build.gradle del proyecto:

plugins {
  id "co.com.bancolombia.serenity-parallel-execution-plugin" version "1.0.2"
}
task parallel(type: ParallelTests, dependsOn: 'clean') {
    srcDirName = 'parallel'
}

Con la primer sección se importa el plugin (para mayor información consulta la documentación del plugin), con la segunda sección se configura la tarea que correrá las pruebas indicándole cuál será la carpeta contenedora de los archivos de propiedades. ¡Y eso es todo! Sencillo, ¿no?, bastará entonces con correr el siguiente comando:

./gradlew parallel

Y… ¡listo!, las pruebas comenzarán a correr en los dispositivos elegidos.

El plugin genera 3 salidas diferentes. Cada salida toma como información el nombramiento de la carpeta contenedora de los archivos de propiedades y el nombramiento de cada uno de esos archivos. Es por esto que se sugieren nombres mnemotécnicos. Así, por cada ejecución se crearán las siguientes carpetas:

build |
      |--parallel: Contiene los logs de gradle por cada dispositivo
target|
      |--parallel: Contiene la documentación viva de Serenity por
      |             cada dispositivo
      |--binary: Contiene los binarios generados por Serenity BDD
                  por cada dispositivo

Así, suponiendo que se ejecutan las pruebas en dos celulares galaxyC5 y galaxyJ3 las salidas serán las siguientes:

build |
      |--parallel|
                 |--galaxyC5.log
                 |--galaxyJ3.log
target|
      |--parallel|
      |          |--galaxyC5|
      |                     |--Contenido de la documentación viva
      |          |--galaxyJ3|
      |                     |--Contenido de la documentación viva
      |--binary|
               |--galaxyC5.bin
               |--galaxyJ3.bin

La tarea no finalizará, hasta que todas las pruebas hayan finalizado y es requerido tener instalado gradle wrapper en el proyecto de automatización.

Contribuciones

Si deseas contribuir al proyecto o conocer más de él, puedes dirigirte al repositorio de git disponible para eso.