Uso de BDD en entornos DevOps

¿Qué es BDD?

Como su propio nombre indica es desarrollo guiado por el comportamiento. Al igual que ocurría con TDD, que realmente es más una técnica de diseño que de testing, BDD es una herramienta de definición de requisitos y funcionalidades que tiene como resultado la automatización de tests de aceptación. Otros nombres que se pueden utilizar pueden ser ATDD (Acceptance Test Driven Development) o Specification by Example.

Por tanto BDD presenta varias ventajas fundamentales:

• Por un lado es una herramienta de alta colaboración entre negocio, desarrollo y QA que permite mejorar el entendimiento de lo que estamos desarrollando, asegurando que construimos el producto correcto de acuerdo a unas especificaciones.
• Proporciona un framework para la automatización de los tests de aceptación, elemento fundamental para poder implementar la entrega continua ya que nos proporciona gran fiabilidad en las entregas.
• Feedback temprano tanto para negocio como para desarrollo. No se espera a finalizar una entrega para probar, si no que se prueba de manera continua con lo que obtenemos feedback continuo.

BDD da respuesta a dos elementos fundamentes en el desarrollo de software:

• Construir el producto correcto.
• Construir el producto correctamente.

Uso de lenguaje común

El fundamento de BDD es el uso de un lenguaje neutro y común a todos los involucrados: negocio, desarrollo y QA. Además, este lenguaje es interpretado también por las máquinas con lo que conseguimos disponer de especificaciones ejecutables y documentación actualizada.

El lenguaje más común es Gherkin, el cual permite, mediante unas pocas palabras claves, (Given – When – Then) describir el comportamiento de una aplicación mediante escenarios. En este artículo no pretendo dar una descripción detallada del lenguaje Gherkin, pero sí quiero indicar que es una pieza fundamental de BDD. En mi opinión, la escritura de unos escenarios correctos y adecuados es la clave que determina el éxito de esta estrategia.

Para ilustrar cómo funciona el lenguaje Gherkin veamos un ejemplo:

En el anterior ejemplo vemos cómo se describiría el escenario para obtener dinero. El ejemplo es muy simple, pero refleja cómo se detalla el comportamiento deseado. La idea es poder especificar una funcionalidad como un conjunto de escenarios que describen dicha funcionalidad.

La reunión de los 3 amigos

Si tan importante es la elaboración de estos escenarios, ¿quién y cuándo debería escribirlos? La respuesta a esta pregunta es la reunión de los tres amigos. En esta reunión se involucra a Negocio, Desarrolladores y Testers. A través de conversaciones y ejemplos escriben de manera conjunta los escenarios que describen cómo se comporta la funcionalidad a desarrollar.

El resultado de esta reunión será un entendimiento compartido de la funcionalidad por parte de todos los involucrados junto con una serie de escenarios escritos en lenguaje Gherkin. Esta reunión sucede al inicio del desarrollo de cada funcionalidad. Y dentro del sprint si estás usando Scrum.

Desarrollo de la aplicación y automatización de los escenarios

Una vez que tenemos definido el comportamiento de la aplicación mediante los escenarios ya podremos comenzar a desarrollar la aplicación que cumple con lo descrito en los mismos. Es importante recalcar que estamos haciendo un Desarrollo Guiado, es decir, no desarrollamos la aplicación y luego hacemos los tests. En este sentido, el proceso de desarrollo es idéntico al seguido por TDD. Elaboramos los tests y, seguidamente, escribimos el código que supera dichos tests.

Para una escritura efectiva de los tests de automatización debemos tener en cuenta que nos movemos en varias capas que deben estar bien separadas:

• Capa de negocio.
• Capa que describe el flujo del negocio.
• Capa técnica.

La estabilidad, claridad y tasa de cambio de cada capa se puede ver en la siguiente figura:

Los desarrolladores y testers se mueven en la capa técnica y de flujo mientras que la gente de negocio se mueve en la capa superior.

El uso de patrones de programación apropiados nos ayudará a movernos en la capa adecuada, como puede ser el pageObject o el Screen Play. Estas buenas prácticas de programación cobran especial importancia a la hora desarrollar tests de interfaz de usuario.

Definición de terminado

En los marcos de trabajo ágiles un concepto de gran utilidad es la definición de terminado, que nos indica cuándo una determinada funcionalidad se puede dar por finalizada. Establece unos criterios comunes y acordados para dar por finalizada una funcionalidad.

Una ventaja de usar una librería tipo Cucumber es que, al ejecutarlo sobre los escenarios descritos, nos creará un reporte indicando cuántas features, escenarios, pasos, etc. hemos implementado y cuántos no.

En función de este reporte se puede ver claramente cuándo una determinada funcionalidad está terminada: cuando todos los escenarios estén automatizados y se superen los tests.

Si estás usando Scrum, toda la definición, desarrollo y automatización ocurren dentro del Sprint. Por lo tanto, solo se aceptará una historia cuando cumpla con la definición de terminado definida.

Integración en la deployment pipeline

Una vez que tenemos escritos los tests podemos incluir la ejecución de los mismos dentro de nuestra pipeline de despliegue y que sirva para dar por buena una determinada versión de nuestra aplicación. El objetivo es proporcionar feedback y confianza en que lo que vamos a desplegar en el entorno de producción pasa con éxito todos los tests de aceptación que hemos desarrollado. Esta integración en la pipeline proporciona transparencia a todos los involucrados en el proceso de desarrollo, desde la gente de negocio hasta la gente de QA pasando por los desarrolladores.