PATRON SCREENPLAY CON MANEJO DE DEPENDENCIAS EN

GRADLE

Configuración de equipo:

- Variables de entorno

- JAVA_HOME: Marca la ruta hasta el jdk de java

- GRADLE_HOME: Marca la ruta a la carpeta gradle del equipo
VARIABLES DEL PATH:

- Marcan la carpeta bin de Gradle y Java

Dependencias necesarias en el archivo build.gradle:
Compile “net.serenity-bdd:serenity-core:${serenity.version}”
Compile “net.serenity-bdd:serenity-junit:${serenity.version}”
Compile “net.serenity-bdd:serenity-cucumber:${serenity.version}”

Compile “net.serenity-bdd:serenity-screenplay:${serenity.version}”
Compile “net.serenity-bdd:serenity-screenplay-webdriver:${serenity.version}”
Para crear un proyecto con estructura del patrón screenplay necesitamos:
- 3 source folders.
o Src/main/java: contiene los paquetes:

Exceptions: contendrá las clases para manejo de excepciones

Questions: contendrá las clases que obtienen los valores que se usaran para
validaciones (en estas clases no se realizan las validaciones, solo se obtienen
los objetos o valores que se usaran para validar)

Interactions (Opcional): clases que realizan acciones repetitivas (cambiar de

frames, realizar esperas, etc.)

Tasks: clases que realizan acciones muy completas (llenar un formulario,

realizar una compra de producto, realizar una consulta a base de datos)

Integration(Opcional): clases que realizan conexiones a bases de datos,

clases que guardan las querys de SQL

Utils (Opcional): Clases con funcionamientos específicos útiles para el

proyecto (encriptar un token, cambiar el formato de una fecha obtenida,
drivers)

Userinterfaces (Opcional): clases donde se realizan los mapeos de objetos

con los que se interactúa en la automatización (objetos de una página web,
móvil o escritorio)

o Src/test/java: contiene los paquetes:

Runners: clases que definen el lanzador (runner) de la prueba automatizada,
debe existir un runner por cada archivo feature

Stepdefinitions: clases que definen los eventos de la prueba automatizada

o Src/test/resources: contiene un folder llamado features donde se guardarán

los archivos *.feature

Feature: es el archivo que describe la prueba que se realizara, está escrita

como historia de usuario yo, como, para, y define los eventos de la prueba
(Given - Dado, When - Cuando, Then - Entonces)
Ejemplo práctico:
Primero se crea un archivo .feature en la carpeta features (se debe tener instalado el plugin
de cucumber en eclipse para que reconozca la extensión del archivo), en este feature se
define el escenario de prueba
Feature:

- #language:es: Sirve para cambiar el lenguaje de los features y los StepDefinitions:

o Feature=Característica; Given=Dado; When=Cuando; Then=Entonces;
Background=Antecedentes; Scenario=Escenario; And=Y; Scenario
Outline=Esquema del Escenario; Examples= Ejemplos.

- Background: Es una tarea que se ejecutara antes de los pasos Given, When Then del
feature, la forma más común de usarlo es para abrir páginas web o para hacer un logueo.

- Scenario Outline: Sirve para declarar varios casos de prueba en un solo escenario con
datos en una tabla, se correrá un caso de prueba pro cada fila en la tabla, para que esta
notación funcione el escenario debe tener la notación examples al final.
 En este caso la tabla debajo del when es la que muestra que parámetros tomara el caso de
prueba, los valores encerrados en <> son los que traen los valores de los Examples como
variables, en este caso el escenario se correrá 4 veces por las 4 filas de la tabla.

Runner:

Es la clase que se encarga de lanzar la prueba automatizada

@RunWith: define que se lanzara la prueba con la clase de CucumberWithSerenity (se puede usar
con otras clases, pero en el caso de screenplay usa esta)

@CucumberOptions: Define el feature que va a lanzar, el paquete de stepdefinitions donde se

encuentran los métodos que realizan la prueba (Al correr la clase runner como una prueba junit en
caso de que los métodos no hayan sido creados a mano en el stepdefinitions el runner leerá el
archivo feature al que está ligado y creara métodos a partir de los pasos definidos en el feature,
estos deben ser pegados en el stepdefinitions correspondiente), los snippets que definen el
formato en el que se crean los métodos (comprar_producto() o comprarProducto())
StepDefinition: Contienen los métodos que se crearon a partir del feature y el runner

Se usan importes estáticos para mejorar la legibilidad de los métodos como en el caso de la
línea 32
- @Before: Son métodos que se ejecutaran antes de empezar la prueba, el actor se debe
definir en un @Before, también se puede hacer procesos como crear archivos en una
carpeta o lanzar un comando por consola, etc.

- OnStage.theActorInTheSpotlight: Hace referencia al último actor nombrado (en este caso

“Juan”) y funciona para llamar al actor a través de otros StepDefinition, por lo que solo
debería nombrarse al actor una vez en el @Before y continuar llamándolo por uso de esta
notación (el actor también puede nombrarse como en la línea 28 pero no es lo más óptimo).

- @After: Son métodos que se ejecutaran después de terminar la prueba, se puede hacer
procesos como crear archivos en una carpeta o lanzar un comando por consola, etc.
Se puede notar que los métodos de este stepdefinitions corresponden con los pasos que
están en el feature que le corresponde, estos son los métodos creados por el runner

- (.*): esto es una expresión regular que sirve para pasar parámetros, en el paso then
el feature tiene el paso User sees the ‘ORDER PAYMENT’ window, en este caso
ORDER PAYMENT es el parámetro que estamos tomando del feature y que estamos
usando para validar

- attemptsTo: es una habilidad del actor para realizar una tarea

utils.drivers:
Se define la instancia de un driver para google Chrome

Userinterfaces:
Se definen los targets (objetos de una página web en este caso) para poder interactuar con
ellos en el momento que se necesite (el constructor privado vacío es para temas de código
limpio)
Tasks:

En esta tarea se realiza la compra de un producto y se usa un condicional para definir dos
flujos de compra diferentes, el metodo performAs es el metodo de la interfaz Task,

El metodo estatico es el metodo que se debe llamar desde el stepdefinition, este metodo
construye un objeto de la clase y recibe los parámetros enviados, luego ejecuta la tarea
necesaria (una tarea puede dentro de ella llamar una interaccion en este caso es Wait),
estos métodos deben nombrarse de forma que al llamarlos en el stepdefinitions formen un
texto legible
Questions:

En esta clase se trae el valor del objeto PAYMENT_LABEL_DONE y lo retornamos hacia el

stepdefinition para que se realice la validación.

En los pasos @Then de los stepdefinitions existe la línea

actorInTheSpotlight().should(seeThat)
Esta es la línea que realiza la comparación del valor pasado por el feature (no solo debe ser
pasado por el feature, puede ser traído de un Excel o de una consulta sql) con el valor traído
por la question, si la comparación es exitosa la prueba será exitosa

1461329