Desarrollo Dirigido por Comportamiento

BDD es uno de los términos de moda en el desarrollo de software en los últimos

años. A pesar de ser un término muy utilizado, no todo el mundo sabe
exactamente qué es eso de BDD, más allá del significado de esas siglas,
Desarrollo Dirigido por Comportamiento (Behaviour Driver Development), ni
cómo puede BDD ayudarnos en nuestro trabajo diario como desarrolladores.

BDD es una evolución de TDD (Test Driven Development o Desarrollo Dirigido

por Pruebas). De hecho, el concepto de BDD fue inicialmente introducido por
Dan North como respuesta a los problemas que surgían al enseñar TDD.

TDD está basado en 2 prácticas: Escribir las pruebas primero, y Refactorizar

después:

TDD: En primer lugar, se escribe una prueba y se verifica que las pruebas fallan.
A continuación, se implementa el código que hace que la prueba pase
satisfactoriamente y seguidamente se refactoriza el código escrito
En BDD también vamos a escribir las pruebas antes de escribir el código fuente,
pero en lugar de pruebas unitarias, lo que haremos será escribir pruebas que
verifiquen que el comportamiento del código es correcto desde el punto de
vista de negocio. Tras escribir las pruebas escribimos el código fuente de la
funcionalidad que haga que estas pruebas pasen correctamente. Después
refactorizamos el código fuente.

Partiremos de historias de usuario, siguiendo el modelo “Como [rol ] quiero [

característica ] para que [los beneficios]”. A partir de aquí, en lugar de describir
en 'lenguaje natural' lo que tiene que hacer esa nueva funcionalidad, vamos a
usar un lenguaje que nos va a permitir describir todas nuestras funcionalidades
de una misma forma, un lenguaje específico para BDD, como Gherkin, del que
hablaremos un poco más adelante.

Este lenguaje con el que vamos a describir las funcionalidades es lo que en DDD
(Domain Driven Design o Diseño Guiado por el Dominio) llaman lenguaje ubicuo,
es decir, un lenguaje semiformal que es compartido por todos los miembros de
un equipo de desarrollo de software, tanto desarrolladores de software como
personal no técnico. Este es uno de los aspectos claves: BDD facilita la
comunicación entre todos los implicados en el desarrollo, sean técnicos o no.

BDD es un proceso de desarrollo de software que trata de combinar los aspectos

puramente técnivos y los de negocio, de manera que tengamos un marco de
trabajo, y un marco de pruebas, en el que los requisitos de negocio formen parte
del proceso de desarrollo.
A la hora de definir cada funcionalidad, una opción es que esa definición venga
por parte del negocio, quién posteriormente se la pasa a desarrollo (o testing),
quienes escriben las pruebas. Es una opción, pero no es la única, y
probablemente tampoco sea la mejor.

Otra opción es que sean los propios desarrolladores quienes escriban esta
definición de las funcionalidades, a partir de la descripción a alto nivel de la
funcionalidad que le ha dado la gente de negocio. Esto hace que los
desarrolladores tengan que ver esa funcionalidad desde el punto de vista de
negocio, y eso es positivo.

Una tercera posibilidad es que estas funcionalidades se escriban conjuntamente

por negocio y desarrollo, por ejemplo durante la reunión del Sprint Planning. De
esta forma pasaríamos de una lista de requisitos priorizada que el product owner
presenta al equipo de desarrollo, a una lista de pruebas de comportamiento que
pasan como tareas al Sprint Backlog.

Se trata de unir la especificación funcional con la documentación de pruebas,

para ayudar a eliminar la distancia entre las personas de negocio y los
desarrolladores.

Gherkin
Gherkin, es un lenguaje comprensible por humanos y por computadoras, con el
que vamos a describir las funcionalidades, definiendo el comportamiento del
software, sin entrar en su implementación. Se trata de un lenguaje fácil de leer,
fácil de entender y fácil de escribir. Es un lenguaje de los que Martin Fowler llama
'Business Readable DSL', es decir, 'Lenguaje Específico de Dominio legible por
Negocio'.
Utilizar Gherkin nos va a permitir crear una documentación viva a la vez que
automatizamos los tests, haciéndolo además con un lenguaje que puede
entender negocio. Otro aspecto interesante es que se puede usar Gherkin en
otros idiomas, no sólo en inglés. Actualmente Gherkin soporta más de 60
idiomas.

Lo bueno de Gherkin es que para empezar a hacer BDD sólo nos hace falta
conocer 5 palabras, con las que construiremos sentencias con las que vamos a
describir las funcionalidades:

• Feature: Indica el nombre de la funcionalidad que vamos a probar. Debe ser

un título claro y explícito. Incluímos aquí una descripción en forma de historia
de usuario: “Como [rol ] quiero [ característica ] para que [los beneficios]”.
Sobre esta descripción empezaremos a construir nuestros escenarios de
prueba.
• Scenario: Describe cada escenario que vamos a probar.
• Given: Provee contexto para el escenario en que se va a ejecutar el test, tales
como punto donde se ejecuta el test, o prerequisitos en los datos. Incluye los
pasos necesarios para poner al sistema en el estado que se desea probar.
• When: Especifica el conjunto de acciones que lanzan el test. La interacción
del usuario que acciona la funcionalidad que deseamos testear.
• Then: Especifica el resultado esperado en el test. Observamos los cambios en
el sistema y vemos si son los deseados.
Lo normal es probar distintos escenarios para comprobar una determinada
funcionalidad. De esta forma vamos a pasar de nuestras historias de usuario a
pruebas de comportamiento automatizables. Para automatizar estas pruebas
necesitamos apoyarnos en herramientas, como Cucumber, que entiende
perfectamente el lenguaje Gherkin.
Cucumber
Cucumber es una de las herramientas que podemos utilizar para automatizar
nuestras pruebas en BDD. Cucumber nos va permitir ejecutar descripciones
funcionales en texto plano como pruebas de software automatizadas.

Cucumber fue creada en 2008 por Aslak Hellesoy y está escrito en Ruby, aunque
tiene implementaciones para casi cualquier lenguaje de programación: JRuby
(usando Cucumber-JVM), Java, Groovy, JavaScript, JavaScript (usando
Cucumber-JVM y Rhino), Clojure, Gosu, Lua, .NET (usando SpecFlow), PHP
(usando Behat), Jython, C++ o Tcl.

Otros frameworks BDD

Cucumer es probablemente la herramienta más conocida y más utilizada para
automatizar pruebas en BDD, pero existen otros frameworks con los que poder
hacer BDD para los lenguajes de programación más habituales:

• Concordion, easyb y JDave para Java.

• Jasmine para Javascript.
• Kahlan para PHP.
• Behave para Python.
• Ginkgo para Go.

Ejemplo de uso
Una de las formas más sencilla de instalar Cucumber para nuestras primeras
pruebas es hacerlo con node. Para ello simplemente debemos ejecutar desde
una ventana de línea de comandos:

npm install -g cucumber

Tras esto, si todo ha ido bien, tendremos cucumber instalado en nuestra
máquina.

Los casos de tests se escriben en archivos con la extensión .feature, y dentro de

cada uno de estos archivos hay uno o más escenarios de prueba. Primero vamos
a crear una carpeta cucumber, dentro de esta una carpeta features, y dentro
nuestro primer archivo .features.

Vamos a partir de una historia de usuario, con el esquema clásico: “Como [As a
human] quiero [ search GenbetDev en Google] para que [find GenvetaDev
website]”, para crear el caso de prueba que vamos a automatizar con Cucumber:

Feature: Buscar GenbetaDev en google

As a human

I want to search GenbetDev en Google

So I can find GenvetaDev website

Scenario: Search for Genbeta Dev

Given I have visited Google

When I search for "GenbetaDev"

Then I see "Genbeta Dev"

Copiamos ese texto en nuestro archivo y lo llamamos 'my_feature.feature'.

Ahora vamos a ejecutar nuestro test. Para ello, suponiendo que estemos en
windows, desde una ventana de comandos ejecutamos:

cucumber-js features/my_feature.feature

En linux sería:

cucumber.js features/my_feature.feature
El resultado será el siguiente:

Esto lo que nos indica es que debemos ahora implementar el código de pruebas
que permita verificar ese test. Una posibilidad sería la siguiente:

module.exports = function() {

this.Given(/^I have visited Google$/, function () {

browser.url('http://google.com');

});

this.When(/^I search for "([^"]*)"$/, function (searchTerm) {

browser.setValue('input[name="q"]', searchTerm);

browser.keys(['Enter']);

});
 this.Then(/^I see "([^"]*)"$/, function (link) {

browser.waitForExist('a=' + link, 5000);

});

Llegados a este punto, al contrario de lo que ocurría con Chimp.js, que se

encargaba de instalar todo lo necesario para poder probar, con Cucumber
tenemos muchas alternativas y somos nosotros los que debemos decantarnos
por unas herramientas u otras como complemento, dependiendo también del
lenguaje de programación que elijamos. Por ejemplo, para pruebas web,
podemos apoyarnos en capybara, cucumber-mink, o en navegadores
como zombie.js o phantom.js, junto con selenium webdriver.