Si recordáis la parte I de este post, hablamos de las historias de usuario o features (en el mundo BDD, aun con diferencias, puedes encontrar las historias de usuario bajo el término features) y de como, con el objetivo de automatizar el testing, cada historia de usuario se escribía usando un lenguaje llamado Gherkin.
Una “feature” contiene la descripción de la historia de usuario y uno o más escenarios (cada escenario vendrá a ser una prueba). Un escenario describe un ejemplo de comportamiento del sistema, son condiciones de aceptación de una historia de usuario y normalmente las proporcionan los product owner.
Si esto era una feature (historia de usuario):
Feature: Tener un Camion
As a Rockero
I want to a Camion
Because I want to be happy
Un escenario está compuesto de pasos:
- Given, dada (condición previa para el escenario),
- When, cuando (ejecutar una acción en la aplicación bajo prueba) y
- Then, entonces (el resultado deseado)
Por ejemplo…
Scenario: haciendo ruido con mi camión
Given yo soy rockero y tengo un camión
When yo toco el claxon
Then suena un ruido estrepitoso que me hace feliz
Lo siguiente será definir cada paso. Es decir, y tirando de un popular ejemplo en el mundo BDD, para el escenario…
Scenario: Cutting vegetables
Given a cucumber that is 30 cm long
When I cut it in halves
Then I have two cucumbers
And both are 15 cm long
Podría escribir, utilizando expresiones regulares, por ejemplo, la siguiente definición:
#encoding: utf-8
Given /^a cucumber that is (\d+) cm long$/ do |arg1|
pending # express the regexp above with the code you wish you had end
When /^I cut it in havles$/ do
pending # express the regexp above with the code you wish you had end
Then /^I have two Cucumbers$/ do
pending # express the regexp above with the code you wish you had
end
Then /^both are (\d+) cm long$/ do |arg1|
pending # express the regexp above with the code you wish you had
end
No me adelanto más en esta segunda parte, y antes de ver con más detalle esas implementaciones, tenemos que ver antes las herramientas capaces de interpretar los escenarios, más concretamente., y como ejemplo de las mismas, vamos ver Cucumber en las siguientes partes de este post.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024