¿Qué es BDD?

BDD refiere a Behavior Driven Development, o sea, desarrollo dirigido por comportamiento. Como bien lo indica su nombre, no se trata de una técnica de testing, sino que es una estrategia de desarrollo (así como TDD, que es test driven development). Lo que plantea es definir un lenguaje común para el negocio y para los técnicos, y utilizar eso como parte inicial del desarrollo y el testing. Por esto es que es importante que vos como tester entiendas bien qué es BDD.

BDD y TDD

A mí me gusta ver BDD como una evolución del TDD. En TDD se enfoca a la prueba unitaria, en cambio en BDD se enfoca en la prueba de más alto nivel, la prueba funcional, la de aceptación, el foco está en cumplir con el negocio y no solo con el código.
Ambos enfoques podrían convivir, ya que se podría especificar una prueba de aceptación, y luego refinar en pruebas unitarias al momento de codificar esa funcionalidad en las distintas capas. Tal vez una ventaja clara de BDD es que los desarrolladores se enfocan en ver qué es lo que tiene que funcionar y de qué forma a nivel de negocio.

BDD en metodologías ágiles

Esta estrategia encaja bien en las metodologías ágiles, ya que generalmente en ellas se especifican los requerimientos como historias de usuario. Estas historias de usuario deberán tener sus criterios de aceptación, y de ahí se desprenden pruebas de aceptación, las cuales pueden ser escritas directamente en lenguaje Gherkin (leer lo que sigue).

Lenguaje común para negocio y técnicos: Gherkin

Gherkin es un lenguaje común, que lo puede escribir alguien sin conocimientos en programación, pero que lo puede comprender también un programa, de forma tal de utilizarlo como especificación de pruebas.
Típicamente, estas pruebas se van a guardar en archivos “.feature”, los cuales deberían estar versionados junto al código fuente del sistema que se está probando. Este es un ejemplo simple tomado de Cucumber:

En estos archivos se especifica:

• Feature: nombre de la funcionalidad que vamos a probar, el título de la prueba.
• Scenario: habrá uno por cada prueba que se quiera especificar para esta funcionalidad.
• Given: acá se marca el contexto, las precondiciones.
• When: se especifican las acciones que se van a ejecutar.
• Then: y acá se especifica el resultado esperado, las validaciones a realizar.

Puede haber un feature por archivo y este contendrá distintos escenarios de prueba.

Nota: Gherkin soporta muchos lenguajes, así que si bien lo más común es verlo en inglés, se podría hacer en español también.

¿Quién escribe las pruebas de aceptación?

Esto creo que depende mucho de cada equipo, pero podrá ser desde el Product Owner o alguien del equipo, ya sea tester o desarrollador. Tal vez una buena opción es hacerlo en conjunto, al menos el brainstorming, como parte del refinamiento de las historias. Luego, el tester se encargaría de asegurarse que estén bien escritas, completas, con el cubrimiento de acuerdo a la estrategia de pruebas definidas.

BDD y testeabiliidad

El enfoque BDD favorece la testeabilidad del sistema. Me atrevo a decir que la mejor forma de hacer funcionar este esquema es con una arquitectura del estilo de microservicios, que permita agregar y trabajar una funcionalidad por todas sus capas en forma independiente. Este esquema facilita las pruebas, entonces mejora la testeabilidad.

Esto me hace acordar al curso de Scrum Master que hice el año pasado con Peregrinus, donde Gabriel mencionaba que en agile lo importante es saber cortar la torta (como lo menciona alguien más en este post). Y en estos párrafos es donde queda claro:

Pensemos en una torta. Básicamente, está formada por capas. Y cada capa aporta su sabor para combinarse con las demás. Si cortáramos la torta en forma horizontal, tendríamos que a algunos les tocaría un pedazo de bizcocuelo, a otros el dulce de leche o la crema, y a otros los merengues. Ningún comensal podría probar todos los sabores combinados, y por consiguiente, ninguno podría decir que realmente probó la torta.

Lo mismo sucede con el enfoque de escribir una user story por componente. Puede funcionar todo bien separadamente, pero cuando intentamos integrar todo, encontramos miles de problemas.

Es por eso que se compara a las stories con una porción de torta (bien cortada). Esta porción debe abarcar desde la cobertura, hasta el piso inferior de bizcochuelo, para que se pueda probar (“testear”) todo junto.

O sea, no debería haber una historia que sea “implementar la funcionalidad XX en la capa de acceso a datos”. Eso no está orientado al negocio. BDD funciona mejor en un sistema testeable, donde la torta está bien cortada, enfocando las historias a una funcionalidad del negocio, y al implementarla (para poder darla por terminada) se deben completar todas sus capas.

BDD para automatizar pruebas

El lenguaje Gherkin es simplemente texto con algunas palabras clave y algo de estructura, que luego hay herramientas como Cucumber o JBehave, que permiten implementar una capa de conexión entre esa especificación de prueba y la interfaz del sistema que se quiere probar, pudiendo así utilizar eso como los pasos de una prueba automatizada.

Para comenzar a practicar un poco, hay un plugin de Google Chrome muy bueno llamado Tidy Gherkin. Uno puede escribir las features en el campo de texto de arriba, y muestra cómo es el código necesario para ejecutar esos pasos en distintos lenguajes (Java, Ruby y JavaScript).

Conclusión

Una buena combinación para trabajar BDD podría ser:

• Tener una arquitectura que permita trabajar en rebanadas, y que estas historias se completen cuando se completa de punta a punta. ¡La torta bien cortada!
• Cuando se refinan las historias, escribir las pruebas de aceptación en Gherkin (puede hacerlo un tester sin conocimiento en programación).
• Se trabaja durante el sprint en el desarrollo. Al inicio del sprint, mientras no hay ninguna historia pronta para probar, el tester que automatiza puede trabajar en quitar deuda técnica de testing.
• Una vez que una historia está lista para probar, se realiza test exploratorio, y si se considera que se puede automatizar, se implementa la capa que conecta el archivo feature con la interfaz del sistema a probar. Esto es usando Cucumber con algún lenguaje (Java, Ruby, etc.), con algún driver apropiado, que puede ser Selenium si probaremos una web, Appium si es algo mobile, SoapUI para servicios web.
• Versionar el código de las pruebas, el código del sistema y las features con el mismo criterio.

¿Tenés alguna experiencia para compartir?