Automatizacion con Serenity BDD, Cucumber y patrón Screenplay

Automatización de pruebas con la librería Serenity BDD y, por tanto, con living documentation. Fue guiado por el patrón de diseño Screenplay y el analizador de lenguaje de Gherkin Cucumber.

La automatización consiste en automatizar tres flujos de la página Demo QA con las rutas:

• Elements > Web Tables → Para realizar registros en la tabla
• Widgets > Date Picker → Para ingresar fechas y fechas con hora
• Alerts, Frame & Windows > Alerts → Para interactuar con los tipos de alertas

Objetivos

Se realizan las pruebas automatizadas para validar:

1. Visualización de datos ingresados
2. Respuesta del sistema ante ingreso de datos incompletos

El resultado de los tests se puede consultar aquí.

El sistema de archivos es:

src
├── main
│   └── java
│       └── com
│           └── challenge
│               ├── exceptions
│               │   └── ExcepcionGeneral.java
│               ├── interactions
│               ├── models
│               │   └── UserData.java
│               │   └── AlertColor.java
│               ├── questions
│               │   ├── IsVisibleThe.java
│               │   ├── ValidateField.java
│               │   └── ValidateText.java
│               ├── tasks
│               │   ├── AddNewRegistry.java
│               │   ├── DeleteRegistry.java
│               │   ├── InteractWithAlerts.java
│               │   ├── NavigateTo.java
│               │   └── SelectNewDate.java
│               ├── userinterfaces
│               │   ├── alerts
│               │   ├── dates
│               │   ├── DemoQaHomePage.java
│               │   ├── DemoQaMenuPage.java
│               │   └── registry
│               └── utilities
│                   ├── CsvToUsersDataRegistry.java
│                   ├── ErrorMessage.java
│                   ├── StringToLocalDateFormat.java
│                   └── WebMenuFromJsonData.java
└── test
    ├── java
    │   └── com
    │       └── challenge
    │           ├── hooks
    │           │   └── SetTheStage.java
    │           ├── runners
    │           │   ├── AddRegistry.java
    │           │   ├── InteractAlert.java
    │           │   └── SelectDate.java
    │           └── stepdefinitions
    │               ├── AddRegistryStepDefinition.java
    │               ├── InteractAlertsStepDefinition.java
    │               └── SelectDatesStepDefinition.java
    └── resources
        ├── features
        │   ├── alerts
        │   │   └── interact_alert.feature
        │   ├── dates
        │   │   └── select_date.feature
        │   └── registry
        │       └── add_registry.feature
        ├── logback-test.xml
        ├── serenity.conf
        └── testdata
            ├── examples_registry.csv
            └── web_menu.json

---

Características

Como la estructura de la página es Menu > Submenu (por ejemplo, Elements > Web Tables), para simplificar la navegación se parametrizó esta estructura con web_menu.json, que es leído por la clase WebMenuFromJsonData y permite definir el flujo como un objeto, así:

{
  "Flow <#>": {
    "<Menu>": "<Submenu>"
  }
}

El llamado al flujo se realiza desde cada Step definition y se le pasa al método para navegar theDemoQaSubPage.

El flujo de registro está construído con pruebas basadas en datos leídos de archivo externo csv. Esto lo permite la clase CsvToUsersDataRegistry, que convierte los datos al modelo UserData y así manejar el registro ingresado en la web table.

El flujo de fechas usa el Scenario Outline para enviar tanto

• fechas en formato ISO como
• fechas con horas y minutos

El flujo de alertas interactúa con los tres tipos de ventanas de alerta del navegador:

• Alert or dialog
• Confirm
• Prompt

En el caso de la alerta Confirm se maneja el retraso de tiempo de 5 segundos que el botón presenta.

En todos los flujos se le hacen preguntas al sistema con las clases en la carpeta questions.

Requisitos

Para correr el proyecto se necesita Java JDK 1.8 u 11 y Gradle, preferiblemente con la versión 7.2.

Para lanzar las pruebas y generar la living documentation en la carpeta /target/site/serenity/:

./gradlew clean build test

O en Windows:

gradlew clean build test

CI/CD

Se usa archivo .yml gradle_test_publish_docs para definir los jobs de Github Actions de construcción y ejecución de pruebas continuas y despliegue a Azure de la documentación.