Si comenzamos a trabajar con Gherkin, nos vamos a dar cuenta de que es un lenguaje realmente sencillo para ser entendido por gente técnica y no tan técnica. Es una manera de realizar una documentación en vivo de nuestro proyecto.
De manera original, el lenguaje se comenzó a utilizar con cucumber, pero ahora existen multitud de variantes que podemos introducir en nuestros proyectos de manera sencilla. Con esta herramienta y este lenguaje, cubrimos un amplio espectro de pruebas para validar el código.
Se nos proporcionan los siguientes elementos de trabajo:
- Feature (característica)
- Scenario (escenario)
- Background (antecedentes)
- Scenario Outline (esquema del escenario)
Ahora, vamos a ver más en detalle todos estos elementos y su utilidad en nuestra batería de pruebas.
- Feature: es el encabezado o el marco de trabajo principal. Tiene un título y una descripción a alto nivel y entendible para todo el mundo. Contiene un número determinado de scenarios que cubren una funcionalidad en concreto.
- Scenario: es la prueba en sí misma. Contiene una serie de pasos como “then”, “when”... pueden existir tantos escenarios como validaciones de nuestro código queramos o como caminos busquemos probar.
- Background: son las precondiciones de los escenarios. De esta manera, nos aseguramos de que no repetimos la prueba y cubrimos la mayor parte de caminos del código.
- Scenario outline: son variables que nos permiten simplificar datos repetidos en diferentes pruebas. De esta manera, no necesitamos escribir N veces todos estos datos.
Como veis, el uso de Gherkin con Cucumber es una manera sencilla y eficaz de probar nuestro código, de tener una documentación viva y de poner en práctica técnicas y ayudas para garantizar las entregas al equipo de Calidad.
Comentarios
Publicar un comentario