BDD y TDD en el mundo real (III)- En desarrollo Agile

En los artículos anteriores de esta serie examinamos en profundidad TDD y BDD. Vimos que TDD nos permite ir de los requerimientos al código, definiendo primero las pruebas y luego implementando y refinando la solución. Por otro lado, BDD nos ayuda a definir y probar todo el flujo de una aplicación –a través de su comportamiento esperado. A partir de las historias de usuario y sus criterios de aceptación definimos tests que permitan codificar dichos criterios con una sintaxis estricta y; luego implementar la funcionalidades que cumplan con los tests.

En este artículo veremos la manera de integrar ambas metodologías dentro de un proceso de desarrollo Agile. Integraremos la aportación de BDD, que nos da visión de la calidad esperada en el alto nivel (la funcionalidad de la historia) y; TDD en la calidad esperada en el bajo nivel (la implementación).

Los procesos Agile y la calidad desde la fuente

Los procesos de gestión de proyectos Agile tienen entre una de sus máximas lograr la calidad desde la fuente, es decir, desde el mismo que se crea el código que implementará la solución.

Una propuesta de proceso de gestión de un proyecto con metodología Agile la expone Jim Highsmith en su libro Agile Project Management. Highsmith divide el ciclo de vida del proyecto en 4 etapas:

• Etapa 1: Envisionar: Se responden al “qué, quien, como” del proyecto. Qué entregar (una visión del producto y el alcance del proyecto). Quién participará (la comunidad de clientes, los gerentes de productos, los miembros del equipo del proyecto y las partes interesadas). Cómo piensan trabajar juntos.
• Etapa 2: Especular: La visión del proyecto es traducida en una lista de historias de alto nivel. Se genera un Roadmap del producto.
• Etapa 3: Explorar/Adaptar
  • Explorar: los miembros del equipo ágil exploran varias alternativas para implementar y cumplir los requisitos de un proyecto. Tres áreas de actividad crítica durante esta fase:
    • Entregar las características planificadas
    • Crear una comunidad de proyecto colaborativa y auto-organizada: equipo.
    • Gestionar las interacciones del equipo con los clientes, la gestión de productos y otras partes interesadas (stakeholders).
  • Adaptar: el equipo revisa los resultados de la ejecución; la situación actual del desarrollo del producto; el rendimiento del equipo respecto el plan y; se adapta según los requisitos. Esta adaptación puede ser:
    • cambiando el enfoque del proyecto
    • cambiando los procesos
    • cambiando el entorno
    • cambiando los objetivos del proyecto, etc.
    • Respondiendo a nuevos requisitos de los clientes
  • Etapa 4: Cierre: finalizar el proyecto de manera ordenada y; capturar las lecciones clave del proyecto (mejora continua).

Este ciclo se muestra en la siguiente imagen, con un detalla de las actividades y procesos susceptibles de tomar parte en cada uno de ellos.

Las metodologías Agile apuestan fuertemente por una retroalimentación temprana en el ciclo de creación de los productos o servicios como principal método para garantizar la calidad desde fuente. Movimientos como DevOps recogen este concepto y lo incorporan en su cuerpo de buenas prácticas para maximizar la salida de un equipo en cuestiones de calidad.

Para ello se fundamentan en pruebas que puedan dar un feedback temprano y medible del grado de calidad del producto; y asimismo proponen la automatización de las mismas como método de optimizar la calidad (a través de la estandarización y eliminación del factor humano)

Mike Cohn define la pirámide de pruebas, como una visión que incluya esta aproximación global de pruebas y feedback temprano, tal como se muestra en el siguiente esquema.

Cohn propone 4 tipos de prueba:

• End-to-End (e2e) o funcionales: prueba el flujo del proceso y asegura que los requerimientos funcionales se cumplen (escenarios felices). Informan cuándo el código falla.
• De interfaz de usuario: Prueba la interfaz de usuario para asegurar que se cumplen las especificaciones.
• De sistema: Prueba el software o hardware en un sistema completo e integrado para evaluar el cumplimiento del sistema con los requerimientos definidos (comúnmente no funcionales).
• Test unitarios: Prueba funcionalidades, casos extremos, límites y excepciones. Los test unitarios informan de dónde falla el código.

Las metodologías que llevamos observando, BDD y TDD, se integran en este esquema dentro de los test End-to-End y Test Unitarios respectivamente.

Por tanto, es deseable combinar ambas metodologías (y tipos de test) dentro de los procesos ágiles, para generar dicho feedback temprano y asegurar la calidad desde el inicio, tanto en todo el flujo (el cuándo), como en el detalle de las implementaciones (el donde) de un producto.

Integrando BDD y TDD

Una posibilidad para integrar ambas metodologías dentro de un proceso Agile se exponen en los fundamentos de DevOps y la reproduzco a continuación:

1. Historias de usuario

En un proceso Agile de desarrollo el ciclo de desarrollo comienza con un backlog de historias de usuario.

Como hemos visto, las historias de usuario deben venir (como parte del Definition of Ready: DoR) unos criterios de aceptación claramente definidos.

2. BDD: Tests e2e/funcionales que fallan

En este punto un test de comportamiento puede ser definido usando las técnicas de BDD que hemos visto. Estas técnicas definen la funcionalidad usando una sintaxis estricta (Gherkin). La funcionalidad especificada prueba los criterios de aceptación de la historia. La especificación del test también es una especificación funcional del sistema.

En este punto, cuando el test de comportamiento es ejecutado, falla (ya que no se generado código aún para implementar la historia).

3. Ciclo TDD

Es momento de definir tests de bajo nivel, los test unitarios, siguiendo el proceso propuesto por TDD. Especificar estos tests es un doble ejercicio: especificar los tests y diseñar una actividad en detalle. Escribir estos tests antes de codificar, como  hemos visto, nos obliga a pensar sobre el diseño del software planificado.

Cuando dichos tests unitarios son ejecutados, fallan, ya que, al igual que antes, aún no hemos escrito una línea de código.

Ahora es momento de escribir el código que resuelva los test unitarios siguiendo el proceso propuesto por TDD. El objetivo es asegurar que todos los tests de bajo nivel corren con éxito. Esto incluye corregir bugs y refactorizar el código del producto y también el de los tests.

4. BDD: Pasar tests y refactorizar

Una vez que todos los tests de bajo nivel han pasado con éxito, podemos ejecutar los tests de alto nivel (e2e o funcionales), ajustando el código, corrigiendo bugs.

La refactorización se repite hasta que todos los tests de funcionalidad y los de bajo nivel son pasados con éxito.

5. Siguiente historia

Este proceso que embebe TDD en un BDD se repite para todas las historias de usuario dentro del ciclo iterativo (un sprint). Al finalizar dicho sprint tendremos la implementación con el nivel de calidad deseado a alto nivel y a bajo nivel; con la ventaja de que la calidad está garantizada de fuente.

Este proceso se represa en el siguiente esquema:

Reflexiones finales

Behavior-Driven Development (BDD) y Test-Driven Development (TDD) son dos metodologías muy potentes que aportan procesos de desarrollo que prima la calidad del desarrollo del producto desde el inicio. BDD nos permite definir y construir escenarios completos y complejos; y probarlos. TDD nos ayuda a construir una clase o un módulo que implementa dicha funcionalidades.

Tal como hemos visto, es posible (y deseable) integrar ambos procesos dentro de un ciclo de vida de proyecto Agile, y permite, además, continuar con el enfoque de desarrollo fluido. Esto lo logramos a través de embeber TDD en BDD dentro de una iteración –lo cual nos aporta como valor añadido, no perder el foco del alto nivel cuando implementamos el bajo nivel; algo muy valioso para ser más óptimo y evitar el desperdicio (waste).

Este proceso de integración encaja perfectamente con el enfoque que proponen metodologías agiles iterativas, como Scrum y está alineado con la filosofía Lean. Es un primer paso para abordar procesos de optimización, como los propuestos por DevOps, a través de la automatización de las pruebas y los procesos de entrega continua.

Finalmente, nos permite obtener los beneficios de un feedback temprano y trabajar con el concepto de calidad desde la fuente; lo cual redundará en la calidad final de nuestro trabajo; en producto que entregamos; y como no, en nuestra propia satisfacción como profesionales.