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.

Fuente: http://www.javiergarzas.com/2014/12/bdd-behavior-driven-development-2.html