Entendiendo qué es BDD (Behavior-Driven Development) (II). Los escenarios

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.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Latest posts by jgarzas (see all)

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *