Escribiendo mejores historias de usuario con Gherkin y Cucumber

Escribir pruebas unitarias automatizadas para el software que construimos puede parecer una gran cantidad de trabajo preliminar sin una clara recompensa. Sin embargo, el beneficio a largo plazo para la salud, la felicidad y la velocidad de su equipo empequeñece la inversión inicial. Entre otros muchos beneficios, las pruebas automatizadas detectan errores, permiten el despliegue continuo y facilitan a los desarrolladores la participación en código desconocido.

Cucumber es una herramienta que nos permite crear pruebas de software automatizadas de una manera fácil de escribir y de leer. Aunque muchos equipos de producto luchan por poner en marcha las pruebas automatizadas (quizás nunca hayan oído hablar de herramientas como Cucumber), casi todos ellos han incursionado sin saberlo en uno de sus componentes clave: Gherkin.

Cuando se utiliza con criterio, escribir los criterios de aceptación en forma de Gherkin es una gran manera de que los equipos definan y acuerden lo que significa «hecho» para las características que construyen. A pesar de su simplicidad, Gherkin es un lenguaje muy matizado. Con ese matiz viene mucha confusión sobre lo que separa una declaración que está bien escrita de una que está mal escrita, especialmente para la gente nueva en Gherkin.

De forma aislada, las peculiaridades de Gherkin pueden parecer confusas, pero cuando se ven en el contexto de las pruebas automatizadas de Cucumber, esas sutilezas tienen mucho más sentido. Este artículo repasa cómo Gherkin y Cucumber encajan para que puedas ver cómo usar Gherkin de forma más efectiva hoy en día. Al final de este artículo, aprenderás cómo funciona una implementación completa de Gherkin + Cucumber y cómo la construcción de una biblioteca de escenarios Gherkin bien escritos allana el camino para las pruebas automatizadas.

Gherkin es un Lenguaje Específico de Dominio para escribir criterios de aceptación que tiene cinco declaraciones principales:

1. Scenario – una etiqueta para el comportamiento que vas a describir
2. Given – el estado inicial del escenario
3. When – una acción específica que el usuario realiza
4. Then – un resultado comprobable, normalmente causado por la acción en When
5. And – esto continúa cualquiera de los otros tres operadores

En conjunto, estas declaraciones describen todas las acciones que un usuario debe realizar para llevar a cabo una tarea y el resultado de esas acciones.

Por ejemplo, un ejemplo de Gherkin en el mundo real podría ser así:

Scenario: User clicks the link
Given I am on the homepage
When I click the provided link
Then I should see the link click confirmation

O para generalizar, así:

Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too

En general, el Product Manager escribe los criterios de aceptación de Gherkin antes de que el equipo comience a trabajar en una característica. Tener los criterios de aceptación esbozados en una estructura fácil de leer y entender hace que sea mucho más fácil para los desarrolladores y diseñadores entender el flujo de usuario previsto. Esto es valioso por sí mismo, pero es sólo una pequeña parte del valor de un Gherkin bien estructurado. Después de todo, hay muchas formas efectivas de escribir descripciones de características (como: As a ___ I want to ___ so that ___) que pueden facilitar la comunicación.

Estos otros enfoques tienen su lugar y en muchos casos son compatibles con Gherkin. Sin embargo, una vez que nos graduamos más allá del QA manual y entramos en las pruebas automatizadas, el verdadero valor de Gherkin pasa a primer plano. Con algunas técnicas inteligentes, los escenarios de Gherkin en inglés que escribimos pueden traducirse automáticamente en código automatizado comprobable. Para ver a qué me refiero, echemos un rápido vistazo al hermano mayor de Gherkin: Cucumber.

Expresiones Regulares

La traducción de los escenarios Gherkin a código utiliza una tecnología llamada Expresiones Regulares, o como se conoce comúnmente, Regex.

El problema que resuelve Regex es encontrar palabras, frases o caracteres específicos dentro de un cuerpo de texto. Para lograr este objetivo, los creadores de Regex definieron un conjunto de caracteres y símbolos que representan la lógica detrás de la coincidencia de partes del texto. Por ejemplo, $ se utiliza para marcar el final de una cadena. Como tal, la expresión regular fox$ coincidiría con silver fox (porque las tres últimas letras son f-o-x) pero no con foxy(porque la última letra es y).

Cucumber utiliza Regex para escanear los escenarios que definimos en busca de las palabras clave de Gherkin (ScenarioGivenWhenThen, y And) y las frases que les siguen. Cuando Cucumber encuentra una frase que reconoce en uno de nuestros escenarios usando Regex, traduce esa frase en código usando algo llamado Step Definitions.

Step Definitions

Los archivos de definición de pasos son como un diccionario de idiomas extranjeros. Le dan a nuestro conjunto de pruebas una forma de traducir los pasos del escenario en inglés en código que podemos ejecutar. En la mayoría de los equipos, los desarrolladores que construirán la función escriben las definiciones de los pasos.

Los archivos de definición de pasos tienen un aspecto parecido a este:

La primera declaración está diciendo «cada vez que encuentres la cadena ‘Voy a la página de inicio’ entonces ejecuta la función visit root_path«.

La segunda afirmación está diciendo «cada vez que encuentres la cadena ‘Debería ver el mensaje de bienvenida’ entonces esperamos que la página actual tenga el texto ‘Hello Cucumber’ en algún lugar de la misma».

Cada paso de un escenario debe tener una definición de paso para que el conjunto de pruebas automatizadas sepa cómo traducir nuestro inglés a código. Con el tiempo escribirás cientos de estas definiciones de paso, muchas de las cuales son reutilizables en todo tu conjunto de pruebas (como el primer paso definido anteriormente).

Caveat: La reutilización de funciones sólo es posible si utilizamos una única frase para una única acción. Si nuestros escenarios utilizan tantoI go to the homepage como I visit the homepage indistintamente, entonces tenemos que mantener dos definiciones de paso separadas para la misma acción. Este código duplicado hace que nuestro conjunto de pruebas sea más difícil de mantener y viola el principio DRY (don’t repeat yourself) del desarrollo de software.

A medida que nuestras aplicaciones y nuestros conjuntos de pruebas crecen, nuestras definiciones de pasos y nuestro número de escenarios crecen junto con ellos. Esto puede desordenarse rápidamente y volverse abrumador. Para ayudar a organizar nuestras suites de pruebas, utilizamos archivos de características.

Archivos de características

Para ayudar a gestionar la complejidad de una gran suite de pruebas, agrupamos nuestros escenarios Gherkin en archivos de características. Los archivos de características son como una lista de verificación virtual para asegurarse de que su software funciona. Además de los escenarios necesarios para probar una característica, los archivos de características también tienen una breve descripción de la característica y cualquier regla de negocio o información adicional que ayuda a describir lo que hace la característica.

Un archivo de características podría ser algo así:

Feature: Some terse yet descriptive text of what is desired
Textual description of the business value of this feature
Business rules that govern the scope of the feature
Any additional information that will make the feature easier to understand
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too Scenario: A different situation
...

Una aplicación puede (y debe) tener muchos archivos de características para describir cómo funcionan sus características. Estas pruebas trabajan juntas para darle una visión general de la salud de su aplicación.

Salida

Cuando ejecutes tu suite de pruebas en la línea de comandos usando Cucumber obtendrás una salida algo así:

$ cucumber -s
Using the default profile...
Feature: Hello CucumberScenario: User sees the welcome message
When I go to the login page
Then I should see the welcome message1 scenario (1 passed)
2 steps (2 passed)
0m0.148s

O para algo más tangible:

$ cucumber -s
Using the default profile...
Feature: Google Homepage SearchScenario: User sees the header
Given I’m on the homepage
Then I see the headerScenario: User can search with "Google Search”
Given I’m on the homepage
When I type "random page” into the search field
And I click the Google Search button
Then I go to the random page search resultsScenario: User can search with "I’m Feeling Lucky”
Given I’m on the homepage
When I type "random page” into the search field
And I click the I’m Feeling Lucky button
Then I go to a random pageScenario: User can see the Terms and Conditions
...15 scenarios (15 passed)
87 Steps (87 passed)
0m3.141s

Echar un vistazo a la salida de la ejecución de tu suite de pruebas te da una forma inmediata de comprobar tu aplicación. Puede mostrar dónde tus cambios rompieron una parte de la funcionalidad antigua o dónde la nueva funcionalidad no está funcionando como se diseñó. Esto hace que sea fácil de localizar y corregir esos problemas para que pueda enviar con confianza.

Envolver

Usar Gherkin para escribir escenarios hace que sea sencillo mostrar los flujos que el producto debe tener. Los archivos de características ayudan a organizar esos flujos en trozos lógicos. Cucumber escanea esos trozos y nos da una lectura en vivo de qué piezas de nuestro software funcionan y cuáles no.

Un conjunto de pruebas completo donde cada característica tiene un archivo de características y un conjunto de escenarios es una herramienta poderosa. Facilita la detección de errores en las nuevas características, para evitar la introducción de errores en las características antiguas, y para comunicar el progreso con las partes interesadas. En resumen, automatiza algunos de los mayores retrasos entre la construcción de una característica y su puesta en manos de los usuarios.

Usar Gherkin y Cucumber no es la única manera de construir pruebas automatizadas de criterios de aceptación, pero es una estructura que es fácil de escalar. Puedes empezar a escribir Gherkin inmediatamente y, a medida que tu equipo madura y crece, empezar a añadir archivos de pasos y pruebas automatizadas con Cucumber. Cuando se usan de forma efectiva, Cucumber y Gherkin nos dan un camino claro (¡e iterativo!) hacia las pruebas unitarias completas y automatizadas.