BDD, Cucumber y Gherkin. Desarrollo dirigido por comportamiento

BDD es entre los términos de tendencia en el desarrollo de software en los últimos tiempos. Pese a ser un término muy empleado, no todo el planeta sabe precisamente qué es eso de BDD, alén del significado de esas iniciales, Desarrollo Dirigido por Comportamiento (Behaviour Driver Development), ni de qué manera puede BDD asistirnos en nuestro trabajo diario como desarrolladores.

BDD es una evolución de TDD (Test Driven Development o bien Desarrollo Dirigido por Pruebas). En verdad, el término de BDD fue en un inicio introducido por Dan North como contestación a los inconvenientes que brotaban al instruir TDD.

TDD está basado en dos prácticas: Redactar las pruebas primero, y Refactorizar después:

TDD: Primeramente, se escribe una prueba y se comprueba que las pruebas fallan. Ahora, se incorpora el código que hace que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito

En BDD asimismo escribiremos las pruebas ya antes de redactar el código fuente, mas en vez de pruebas unitarias, lo que vamos a hacer va a ser redactar pruebas que comprueben que el comportamiento del código es adecuado desde la perspectiva de negocio. Tras redactar las pruebas escribimos el código fuente de la funcionalidad que haga que estas pruebas pasen apropiadamente. Después refactorizamos el código fuente.

Vamos a partir de historias de usuario, siguiendo el modelo “Como [rol ] deseo [ característica ] a fin de que [los beneficios]”. Desde acá, en vez de describir en 'lenguaje natural' lo que debe hacer esa nueva funcionalidad, vamos a emplear un lenguaje que nos va a permitir describir todas y cada una nuestras funcionalidades de una misma forma, un lenguaje concreto para BDD, como Gherkin, del que vamos a hablar un tanto más adelante.

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

BDD es un proceso de desarrollo de software que trata de conjuntar los aspectos puramente técnivos y los de negocio, de forma que tengamos un marco de trabajo, y un marco de pruebas, en el que los requisitos de negocio formen una parte del proceso de desarrollo.

En el momento de delimitar cada funcionalidad, una alternativa es que esa definición venga por la parte de negocio, quién más tarde se la pasa a desarrollo (o bien testing), quienes escriben las pruebas. Es una alternativa, mas no es la única, y seguramente tampoco sea la mejor.

Otra alternativa es que sean los propios desarrolladores quienes escriban esta definición de las funcionalidades, desde la descripción a alto nivel de la funcionalidad que le ha dado la gente de negocio. Esto causa que los desarrolladores deban ver esa funcionalidad desde la perspectiva de negocio, y eso es positivo.

Una tercera posibilidad es que estas funcionalidades se escriban de forma conjunta por negocio y desarrollo, por servirnos de un ejemplo a lo largo de la asamblea del Esprint Planning. De este modo 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 labores al Esprint Backlog.

Se trata de unir la especificación funcional con la documentación de pruebas, para asistir a quitar la distancia entre las personas de negocio y los desarrolladores.

Gherkin

Gherkin, es un lenguaje entendible por humanos y por ordenadores, con el que describiremos las funcionalidades, definiendo el comportamiento del software, sin entrar en su implementación. Se trata de un lenguaje simple de leer, simple de comprender y simple de redactar. Es un lenguaje de los que Martin Fowler llama 'Business Readable DSL', esto es, 'Lenguaje Concreto de Dominio inteligible por Negocio'.

Usar Gherkin nos va a permitir crear una documentación viva al unísono que automatizamos los tests, haciéndolo además de esto con un lenguaje que puede comprender negocio. Otro aspecto interesante es que se puede emplear Gherkin en otros idiomas, no solo en inglés. Hoy día Gherkin aguanta más de sesenta idiomas.

Lo bueno de Gherkin es que para comenzar a hacer BDD solo nos hace falta conocer cinco palabras, con las que edificaremos sentencias con las que describiremos las funcionalidades:

Feature: Señala el nombre de la funcionalidad que probaremos. Ha de ser un título claro y explícito. Incluímos acá una descripción en forma de historia de usuario: “Como [rol ] deseo [ característica ] a fin de que [los beneficios]”. Sobre esta descripción empezaremos a edificar nuestros escenarios de prueba.
Scenario: Describe cada escenario que probaremos.
Given: Provee contexto para el escenario en que se marcha a ejecutar el test, como punto donde se ejecuta el test, o bien prerequisitos en los datos. Incluye los pasos precisos para poner al sistema en el estado que se quiere probar.
When: Detalla el conjunto de acciones que lanzan el test. La interacción del usuario que activa la funcionalidad que queremos testar.
Then: Detalla el resultado aguardado en el test. Observamos los cambios en el sistema y vemos si son los deseados.

Lo normal es probar diferentes escenarios para revisar una determinada funcionalidad. Así pasaremos de nuestras historias de usuario a pruebas de comportamiento automatizables. Para mecanizar estas pruebas precisamos apoyarnos en herramientas, como Cucumber, que comprende de manera perfecta el lenguaje Gherkin.

Cucumber

Cucumber es entre las herramientas que podemos emplear para mecanizar nuestras pruebas en BDD. Cucumber nos va permitir ejecutar descripciones funcionales en texto plano como pruebas de software automatizadas.

Cucumber fue creada en dos mil ocho por Aslak Hellesoy y está escrito en Ruby, si bien tiene implementaciones para prácticamente cualquier lenguaje de programación: JRuby (utilizando Cucumber-JVM), Java, Groovy, JavaScript, JavaScript (utilizando Cucumber-JVM y Rhino), Clojure, Gosu, Lua, .NET (utilizando SpecFlow), PHP (utilizando Behat), Jython, C o bien Tcl.

Otros frameworks BDD

Cucumer es seguramente la herramienta más famosa y más empleada para mecanizar pruebas en BDD, mas hay 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 maneras más fácil de instalar Cucumber para nuestras primeras pruebas es hacerlo con node. Para esto sencillamente debemos ejecutar desde una ventana de línea de comandos:

npm install -g cucumber

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

Los casos de tests se escriben en ficheros con la extensión .feature, y en cada uno de ellos de estos ficheros hay uno o bien más escenarios de prueba. Primero crearemos una carpetita cucumber, en esta una carpetita features, y dentro nuestro primer fichero .features.

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

Feature: Buscar turincon.netDev en google
As a human
I want to search GenbetDev en Google
So I cánido find GenvetaDev website
Scenario: Search for turincon.net
Given I have visited Google
When I search for turincon.netDev
Then I see turincon.net

Copiamos ese texto en nuestro fichero y lo llamamos 'my_feature.feature'. Ahora vamos a ejecutar nuestro test. Para esto, 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 va a ser el siguiente:

Esto lo que nos señala es que debemos ahora incorporar el código de pruebas que deje contrastar ese test. Una posibilidad sería la siguiente:

module.exports = function() undefined

Llegados aquí, al revés de lo que ocurría con Chimp.js, que se ocupaba de instalar todo lo preciso para poder probar, con Cucumber tenemos muchas opciones alternativas y somos los que debemos decantarnos por unas herramientas o bien otras como complemento, dependiendo asimismo del lenguaje de programación que escojamos. Por servirnos de un ejemplo, para pruebas web, podemos apoyarnos en capybara, cucumber-mink, o bien en navegadores como zombie.js o bien phantom.js, así como selenium webdriver.

Asimismo te invitamos a

EDD: Fallo Driven Development. Volviendo a los comienzos. Afirmemos adiós al postureo

Republic of Gamers: de qué forma reinventar el gaming durante diez años

HTML5 Constraint API

– La nueva

BDD, Cucumber y Gherkin. Desarrollo dirigido por comportamiento

fue publicada originalmente en

turincon.net

por
Raúl Hernández