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.
La pruebas automatizadas se agruparán en un módulo de la aplicación llamado <nombre-proyecto>-testproject.
Directorio es.ja.csalud.sas.$sistemaInformacion$.cucumber. Contendrá los siguientes paquetes:
Incluirá tantos directorios como subsistemas tenga el proyecto a automatizar con los archivos .feature que corresponderán a los diferentes casos de pruebas.
Contendrá las clases lanzadoras de las pruebas para Cucumber
(Imagen)
Este directorio stepdefinition también podrá estar dividido por subsistemas. Tendremos tantas clases como casos de pruebas (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.
El directorio step contiene las operaciones a bajo nivel. Habrá una clase por cada funcionalidad que tiene la aplicación.
Las clases que contendrán el DOM de los elementos de la aplicación a automatizar, o el patrón Page Object Model.