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.

Dejar un comentario

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