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.

Pautas para las pruebas funcionales a través de interfaz

DIRECTRIZ 9

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.