Las mejores prácticas en Gherkin Cucumber
Artículo de Kenan Rhoton
¿Cuáles son las mejores prácticas con Gherkin Cucumber?
A lo largo de los años de trabajo con Cucumber (y Gherkin), haciendo qa testing tenemos varias pautas que nos ayudan a crear mejores escenarios.
A continuación enumeramos las que nos parecen más útiles y que aplicamos a cualquier proyecto que comenzamos con Gherkin Cucumber.
Mejores prácticas en Gherkin Cucumber 1: Escribir características declarativas
Los escenarios deben ser escritos tal y como un usuario los describiría.
Ten cuidado con los escenarios que sólo describen cómo hacer clic en los enlaces y rellenar los campos del formulario, o con los pasos que contienen código o selectores CSS.
Gherkin no es más que una variante de la programación, pero no consiste en una descripción de características de tu software.
Las características declarativas han de ser descriptivas, concisas y contienen pasos altamente mantenibles.
# Mal: esto es sólo programación
Given the user is on "http://www.mypage.com/home"
When the user clicks on the first news item
Then the browser shows the news item view page
# Bien: claro, legible y relacionable
Given the user is on the Home page
When the user reads the news
Then the user can see the article
# Feo: A pesar de ser legible, no está claro lo que estamos probando
Given the user wants to see news
Then the user sees newsMejores prácticas en Gherkin Cucumber 2: Incluir una narrativa
Las narrativas describen en una frase lo que hace una funcionalidad.
Un ejemplo típico contiene el rol que necesita la funcionalidad, la función propiamente dicha y el beneficio que obtiene el usuario.
Es importante que se vea por qué se implementa la función en primer lugar cuál es la funcionalidad.
También dan una breve visión general de la funcionalidad para que otros tengan una comprensión aproximada sin necesidad de leer los escenarios.
# Mal: ¿Qué estamos probando aquí?
Feature: Reservations
Scenario: User makes a normal reservation
# Bien: Tanto los motivos como lo que se está probando aparecen claramente
Feature: Perform a reservation
As a registered user
To ensure the restaurant has a table available
The user makes a reservation
Scenario: The user successfully makes a reservation
# Feo: Esto es demasiado largo, nadie lo leerá
Feature: The user intends to make a reservation and does so
As a user that has an account on the site
Since they are having an event, be it a bachelor party or birthday or even just a romantic dinner for two, and they want to make sure that they will have a place available to them for this event
The user logs into the page and chooses a restaurant to his liking to make a reservation for said event
Mejores prácticas en Gherkin Cucumber 3: Evitar pasos conjuntivos
Cuando encuentres un paso de Cucumber que contenga dos acciones conjuntadas con un "y", normalmente deberías al menos considerar dividirlo en dos pasos.
Si te ciñes a una acción por paso, tus pasos serán más modulares y reutilizables.
Sin embargo, esta no es una regla general. Puede haber razones para realizar pasos conjuntos. Sin embargo, la mayoría de las veces es mejor evitarlos.
# Mal: Este paso contiene dos estados diferentes
Given the user is logged in with a product in their cart
# Bueno: Cada paso es una declaración sobre el estado
Given the user is logged in
And the user has a product in their cart
# Feo: Estos pasos pueden ser agrupados
Given the user is on the site
And the user has an account
And the user logs into their account
And the user wants to buy a product
And the user adds it to their cartMejores prácticas en Gherkin Cucumber 4: Utilizar los Backgrounds con prudencia
Si utilizas los mismos pasos al principio de todos los escenarios de una función, póngalos en el background de la funcionalidad.
Los pasos de background se ejecutan antes de cada escenario. Pero si añadimos demasiados pasos al background, tus escenarios pueden volverse difíciles de entender.
# Mal: ¡Nos estamos repitiendo!
As a cat lover
The user would like to enjoy pictures of cats
So they go to their gallery
Scenario: The user views pictures of cats
Given the user is logged in
When the user goes to the "Cats" gallery
Then the user can see pictures of cats
Scenario: The user likes a picture of a cat
Given the user is logged in
When the user goes to the "Cats" gallery
And the user likes a picture
Then the user can see that picture in their "Liked" gallery
# Bien: No nos repetimos :)
As a cat lover
The user would like to enjoy pictures of cats
So they go to their gallery
Background:
Given the user is logged in
And the user goes to the "Cats" gallery
Scenario: The user views pictures of cats
Then the user can see pictures of cats
Scenario: The user likes a picture of a cat
When the user likes a picture
Then the user can see that picture in their "Liked" galleryMejores prácticas en Gherkin Cucumber 5: Escenarios de un uso único
Los escenarios deben ser escritos con un caso de uso único en mente.
Esto ayuda a localizar los errores y encontrar exactamente qué casos fallan.
También ayuda a entender exactamente qué se está probando y por qué.
# Mal: el escenario cubre demasiadas cosas
Scenario: Cart
Given the user is in the shopping page
When the user adds potatoes to the cart
Then the cart contains potatoes
When the user clears the cart
Then the cart is empty
When the user adds potatoes to the cart
And the user clicks on checkout
Then the user is asked for the payment method
# Bien: un escenario por caso de uso
Background:
Given the user is in the shopping page
And the user adds potatoes to the cart
Scenario: Potatoes added to cart
Then the cart contains potatoes
Scenario: Cart cleared
When the user clears the cart
Then the cart is empty
Scenario: Checkout
When the user clicks on checkout
Then the user is asked for the payment methodMejores prácticas en Gherkin Cucumber 6: Sigue el patrón Estado-Acción-Estado
Los escenarios deben declarar un estado inicial (Given), realizar algunas acciones (When) y asegurarse de que se alcanza el estado final esperado (Then).
Esto ayudará a asegurar que los escenarios sean legibles y útiles. Descubre cuál es la razón de llamarlo Given When Then
# Mal: demasiado confuso para leer
Scenario: User successfully logs in
Given the user is in the login page
When the user authenticates correctly
Then the user should see the homepage
When the user clicks on his profile
Then the user should see his personal information
# Bien: hacer que el paso de autenticación compruebe su propio éxito lo hace más legible
Scenario: User successfully logs in
Given the user is in the login page
When the user authenticates correctly
And the user clicks on his profile
Then the user should see his personal informationMejores prácticas en Gherkin Cucumber 7: No seas demasiado extenso
Una buena regla general es intentar mantener los escenarios dentro de 5 o menos pasos.
En algunos casos pueden ser necesarios más, pero sólo en muy pocas ocasiones deberíamos ir más allá de 7.
# Mal: ¡demasiado largo!
Scenario: User successfully registers a new account
Given the user is on the login page
When the user goes to the registration form
And the user fills in his name
And the user fills in his email address
And the user fills in a sufficient quality password
And the user selects a home country "Spain"
And the user submits the registration form
Then the user is successfully registered on the platform
# Bien: ser conciso es una virtud
Scenario: User successfully registers a new account
Given the user is on the login page
When the user correctly fills in the registration form
Then the user is successfully registered on the platformMejores prácticas en Gherkin Cucumber 8: Pasos
Por último, un par de consideraciones que siempre hay que tener en cuenta a la hora de programar los propios pasos:
Hacer pasos autocontenidos: Cada paso debe validar el estado inicial antes de la acción y el estado final después de la misma. Esto da lugar a mensajes más significativos, ya que de lo contrario un problema en la acción de un paso podría dar el paso por válido y devolver el fallo en el paso siguiente.
Reutilizar funciones: En Cucumber puedes llamar a pasos dentro de otros pasos. No hagas esto. En su lugar crea una función que pueda ser llamada desde múltiples pasos. Deberías intentar reutilizar funciones tan a menudo como sea posible. Esto mejorará la mantenibilidad de tu aplicación: si necesitas cambiar un determinado comportamiento, sólo tienes que cambiar una única función.
Conoce a Redsauce y descubre estos consejos y muchos más en nuestro ebook gratuito.