Pautas para la automatización

Introducción

El objetivo de este artículo es exponer una serie de directrices relacionadas con la implementación de las pruebas funcionales automatizadas. Es importante señalar que esta página es sólo una parte de la normativa que está pendiente de publicar.

Con respecto a las herramientas necesarias para llevar a cabo la automatización de las pruebas, el documento se basa en la triada Gherkins-Cucumber-Selenium. Sólo las dos primeras (Gherkins y Cucumber) son de obligado uso. El equipo de arquitectura junto con la OCa evaluará cualquier propuesta alternativa a Selenium que se pretenda utilizar.

DIRECTRIZ 1: Estructura del proyecto. Nombre y ubicación del código

La pruebas automatizadas se agruparán en un módulo de la aplicación llamado <nombre-proyecto>-testproject.

DIRECTRIZ 2: Estructura del proyecto. Carpetas principales

Directorio es.ja.csalud.sas.$sistemaInformacion$.cucumber. Contendrá los siguientes paquetes:

• es.ja.csalud.sas.$sistemaInformacion$.cucumber.feature
  

 Incluirá tantos directorios como subsistemas tenga el proyecto a automatizar con los archivos .feature que corresponderán a los diferentes casos de pruebas.

• es.ja.csalud.sas.$sistemaInformacion$.cucumber.testrunner

Contendrá las clases lanzadoras de las pruebas para Cucumber

• es.ja.csalud.sas.$sistemaInformacion$.cucumber.stepdefinition

Este directorio stepdefinition también podrá estar dividido por subsistemas. Tendremos tantas clases como casos de pruebas. Estas clases tendrán instanciada un objeto de la clase caso de prueba con la coletilla step (por ejemplo CP001_001step) y tantos métodos (paso1) como pasos tenga dicho caso de prueba. También, deben tener como mínimo la llamada a los métodos imprimirPaso e imprimirResultadoEsperado de la librería utilidades (consultar el apartado correspondiente) para verificar que se está realizando el paso y cómo ha finalizado.

• es.ja.csalud.sas.$sistemaInformacion$.cucumber.step

El directorio step contiene las operaciones a bajo nivel. Habrá una clase por cada funcionalidad que tiene la aplicación.

• es.ja.csalud.sas.$sistemaInformacion$.cucumber.pageobject

Las clases que contendrán el DOM de los elementos  de la aplicación a automatizar, o el patrón Page Object Model.

Directorio es.ja.csalud.sas.$sistemaInformacion$.integración. Para el caso en el que se vayan a implementar pruebas de integración, este paquete contendrá los XML necesarios para realizar pruebas a los web services y que son implementados en la herramienta SoapUI.

DIRECTRIZ 9: Buenas prácticas. Uso de Page Object Model

La ejecución automatizada de un conjunto de pruebas funcionales requiere de un modelo de clases que de soporte a su implementación y que sirva de marco para cualquier proyecto desarrollado por y para la STIC. Para ello, el patrón a seguir es “Page Object” que consiste en crear un objeto por cada conjunto de elementos significativos de la interfaz con la que se interactúa. Aunque el nombre sugiera (y generalmente suceda) que cada objeto debe representar una página de la navegación del sistema de información, si dentro de la página existen componentes visuales reutilizables en otras partes, es necesario construir un Page Object de ese elemento para poder reutilizarlo. De esta forma, si se realiza un cambio en la interfaz de usuario, el cambio solo se realiza una única vez, y éste se vea reflejado en todos los test del sistema.

El patrón indicado se sustenta bajo el siguiente modelo:

Por tanto, se encuentran las clases Page Objects donde se ha de implementar los elementos de la interfaz de usuario que permiten interactuar con el sistema de información. Y por otro lado las clases de test con las pruebas a realizar, donde se desarrolla la lógica del test utilizando los elementos descritos en las clases Page Object. Por último, es necesario y fundamental tener presente los distintos navegadores donde se pueden ejecutar los casos de prueba.

Directriz 10: Buenas prácticas. Uso de framework y librerías

Para la codificación de las pruebas automatizadas se recomienda el uso del siguiente conjunto de herramientas:

• JUnit: Framework para la ejecución de test unitarios y de integración.
• TestNG: Framework basado en JUnit pero que cubre el espectro completo de pruebas: unitarias, integración, funcionales, end-to-end…
• Selenium: Framework para la ejecución de scripts de pruebas sobre un navegador web.
• LogBack: Framework para la generación de trazas. Teniendo que guardar en ellas los pasos del proceso de cada prueba.
• Librería de Utilidades: Se recomienda el uso de una librería de Utilidades que ha sido desarrollada por el equipo de la Oficina de Calidad y que contiene las acciones básicas para inicializar el driver, escribir el log, etc. A continuación se describe cómo hacer buen uso de ella, asñi como alguna de sus funcionalidades.
  •  Se tendrá que instanciar un objeto de tipo UtilSelenium y la clase que instancie el objeto UtilSelenium hereda de la clase BasePrueba de la librería. Para instanciar dicho objeto se utiliza el método getInstancia el cual recibe tres parámetros. 
    • Nombre del log
    • Navegador a utilizar en la prueba
    • Versión del Selenium WebDriver a utilizar
  • imprimirPaso para escribir en el log el paso X (autoincremental) y la información que se pasa como texto. Recibe un parámetro: