Debe haber centenares post sobre BDD y sí… este es uno más, con las características especiales de estar en español y estar escrito y pensado para aquellos que desconocíais el tema BDD por completo y queráis en poco tiempo “saber de qué va” esto, de sacar la idea principal de por qué esto del BDD es importante y por qué cada vez se habla más de ello.
En las próximas semanas iré dejando un post sobre BDD y relacionados, este es una primera y básica introducción, el siguiente será probablemente de Cucumber, etc. Me vais a disculpar que no fije un día exacto para esta serie de post “BDD”, pero es que ando demasiado liado para poder comprometerme a un día exacto (de hecho, créeme, este post que lees, y otros restos de la serie, lo empecé en abril y lo he ido terminando a ratos)
Estaría encantado de recibir comentarios, mejoras, detalles, añadidos y demás, sé que entre los lectores del blog hay auténticos expertos en BDD, animaros y me ayudáis a difundir el conocimiento sobre el tema del BDD y de “las buenas pruebas”.
Vamos a ello…
¿Qué es eso de BDD?
Behavior-Driven Development o BDD es un proceso de desarrollo software, si bien se relaciona principalmente con el Testing, que es de donde surge.
BDD busca un lenguaje común para unir la parte técnica y la de negocio, y que sea desde ese lenguaje común desde donde arranque el Testing y, desde ahí, el desarrollo.
En BDD, las pruebas de aceptación se escriben usando historias de usuario, ya sabes aquello tan usado en agilidad (sino léete el anterior post)… “Como [rol ] quiero [ característica ] para que [los beneficios].”
Y, siguiendo con lo anterior, posteriormente escribir criterios de aceptación para esas historias de usuario, haciéndolo en términos de escenarios:
Dado [contexto inicial], cuando [se produce el evento], entonces [resultados]
Given [initial context], when [event occurs], then [ensure some outcomes].
Así, simplificadamente, el ciclo básico de BDD sería el siguiente…
1 – Escribir las historias de usuario.
2 – Escribir los escenarios.
3 – Automatizar las pruebas de aceptación.
Ya sabes, con la idea final de tener un mismo “framework” de comunicación y colaboración entre desarrolladores, QA y roles no técnicos, o de negocio, en un proyecto de software. Y para tener ese punto común entre todos esos actores, algo clave es tener un lenguaje común, y ahí es donde aparece Gherkin…
Gherkin
Las historias de usuario que comentamos antes, o features (en el mundo BDD puedes encontrar las historias de usuario bajo el nombre de features, hay quien dice que no son exactamente lo mismo, pero para nosotros por ahora sí lo son), lógicamente, las escribe negocio, es responsabilidad del product owner.
En BDD, lo que haremos será, con el objetivo de automatizar el testing, aparte de tener historias en pósit, como ha sido de toda la vida, cada historia de usuario se escribirá usando un lenguaje “de programación”, llamado Gherkin (la traducción es pepinillo), y se guardarán en un fichero, de extensión .feature (normalmente dentro de un directorio llamado “features”, para más datos).
Gherkin es un lenguaje entendible por el negocio, lo que se llama un DSL (Domain-Specific Language), más o menos cercano al lenguaje natural. Está pensado para que lo entienda “negocio”, los usuarios, etc. Su idea es contar como se “comporta” el software sin entrar en detalles de implementación.
Es un lenguaje muy simple. Sólo tienen 5 sentencias:
Feature:
Scenario:
Given
When
Then
Estas features serían historias de usuario. Y como es típico en una historia de usuario, deben tener el “As a / I want to / Because”. Vamos con un ejemplo, la historia de usuario “Tener un Camión”:
Feature: Tener un Camion
As a Rockero
I want to a Camion
Because I want to be happy
Así que Gherkin nos sirve para documentar y para automatizar lo que luego se convertirá en test, haciéndolo con un lenguaje que puede entender negocio, o cualquier product owner, y que además puedes usar en otros idiomas más allá del inglés, hasta la fecha en 40 idiomas.
Luego necesitaremos una herramienta que entienda los .feature, por ejemplo, Cucumber (para Ruby), que cuando lo lanzas genera un informe que verifica si el software se comporta como el fichero Gherkin dice. Para ello, alguien del equipo habrá escrito código que transforma el texto de Gherkin en interacciones con el código a probar, pero antes, para ello, necesitaremos escenarios asociados a cada historia de usuario, que nos den ejemplos de cómo debe comportarse el software implementado para esa historia.
Esos escenarios serán el paso intermedio entre la historia de usuario y la implementación de una prueba automatizada. Pero como este post ya se me a alargado demasiado… los escenarios y herramientas como cucumber… lo dejo para la segunda parte.
Fuente: http://www.javiergarzas.com/2014/12/bdd-behavior-driven-development-1.html
No hay comentarios:
Publicar un comentario