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.

Estructura del proyecto

DIRECTRIZ 1: 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: 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.