...

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

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

En el caso de no utilizar la librería "Utilidades" ofrecida por la OCA, es necesario la creación de un paquete "common" en el que se inicialicen los distintos navegadores para los que está certificada la aplicación.  Además, deberá contener los métodos que sean reutilizables para todos los elementos, como las esperas (implícitas o explicitas), la generación de capturas de pantalla o la interacción con el log.

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.

...

• Al inicio del archivo se colocará la etiqueta @id_historiaDeUsuario. Es importante señalar que el id de la historia de usuario al que nos referimos es el correspondiente al del JIRA de la STIC.
• En lo relativo a las pre condiciones, se crearán tantas como la palabra "Given" aparezca tras el Background. Si la pre condición ya estuviese creada, se podrá enlazar a la prueba colocando la etiqueta @id_precondicion, donde el id de la pre condición será el del JIRA de la STIC.
• Se creará una prueba por cada escenario. Las etiquetas obligatorias que deberán colocar sobre cada escenario serán: @id (identificador único). @AUTO_Nombre del proveedor (por ej.: @AUTO_INDRA o @AUTO_EVERIS) y @nombre_componente (si la aplicación está dividida en subsistemas).

Toda la información relacionada con este tema puede consultarse pulsando en el siguiente enlace: https://confluence.xpand-it.com/display/public/XRAY/Importing+Cucumber+Tests+-+REST 

Codificación de pruebas

DIRECTRIZ 8: Codificación de tests unitarios

Para la ejecución de las pruebas dentro del flujo de integración continua, es necesario crear las clases de tipo TestNG. Para la codificación de cada clase TestNG se utilizarán mínimo las siguientes anotaciones:

• @DataProvider: Es un método para suministrar los datos necesarios al @test. Este método debe devolver un Object[x][y] que corresponde con los distintos test case que van a ejecutarse en el @test.
• @Parameters: Describe cómo pasar los parámetros al método @Test.
• @Test: Método para ejecutar el test. Es necesario pasarle por parámetros el DataProvider.

Por otro lado, podrían ser de utilidad las siguientes:

• @BeforeSuite - @AfterSuite:  Este método se ejecutará antes - después de lanzar todos los test suite.
• @BeforeTest - @AfterTest: Este método se ejecutará antes - después de lanzar los métodos que pertenecen a las clases <test>.
• @BeforeClass - @AfterClass: Este método se ejecutará antes - después del método @test de la propia clase.
• @BeforeMethod - @AfterMethod: Este método se ejecutará antes - después de cada método @test.

Aquellos tests en los que no sean necesario incluir su ejecución por el momento se pueden excluir de la ejecución global indicándolo en el XML Suite de la siguiente forma:

Image Added

DIRECTRIZ 9: Uso de cucumber

Para la codificación de cada background y de los pasos de cada scenario se utilizarán las siguientes keywords:

...

Adicionalmente se puede incluir la keyword @After para definir los pasos a ejecutar después de la prueba.

...

Para la ejecución de las pruebas dentro del flujo de integración continua, es necesario crear una clase lanzadora con la siguiente información como mínimo:

Image Added

DIRECTRIZ 10: Etiquetado

A continuación se describen un conjunto de tags a usar para la ejecución o no de escenarios durante las pruebas. Los tags son anotaciones que sirven para agrupar y organizar escenarios e incluso features, estos se escriben con el símbolo @ seguido de un texto significativo. Ejemplos:

...