TDD vs BDD
Estas son dos técnicas diferentes. La clave de cada una está en la mentalidad y el contexto de lo que quieres lograr.
BDD es una “funcionalidad guiada por tests”
Básicamente, es un desarrollo test-first, donde el enfoque principal es asegurar el comportamiento final esperado, y por lo tanto el resultado de la lógica de software que quieres tener al final.
En BDD el enfoque principal es el comportamiento de tu lógica de dominio que aún no existe. Es, desde un punto de vista abstracto, sobre toda la funcionalidad y los requisitos del dominio.
TDD es sobre el ritmo
- Especifica lo que quieres.
- Hazlo funcionar.
- Hazlo mejor.
TDD no es solo la ya conocida mentalidad “red-green-refactor”, sino principalmente sobre el flujo de trabajo que te ayuda a entender las constantes decisiones de diseño que haces cada vez para cada lógica que estás diseñando.
TDD es sobre retroalimentación constante de tus decisiones.
En el contexto de OOP (para hacer los ejemplos más claros), siempre hay toneladas de formas diferentes de diseñar tu clase:
- ¿Cuál es el nombre de la clase de este método?
- ¿Cuáles son las dependencias o colaboradores de esta clase?
- ¿Cómo se comportará esta clase cuando use esta otra clase dentro de ella?
- ¿Cuál es el resultado esperado de este método cuando le doy estos argumentos?
- etc, etc…
Hacemos estas preguntas (y muchas más) cada vez, y también les damos una respuesta, pero normalmente sin ningún pensamiento racional o reflexión sobre ello. Simplemente hacemos lo que creemos que es “lo mejor” en ese momento particular enfocándonos en hacer que algo funcione, pero ¿es suficiente hacerlo funcionar?
El bucle de retroalimentación constante
El testing no es solo una gran herramienta porque te da una red de seguridad para refactorizar con confianza, sino también porque ayuda a diseñar mejor el sistema. ¿Cómo es eso? Porque antes de implementar cualquier solución, te obliga a pensar en las decisiones que necesitas tomar. Te desafías a ti mismo para entender los argumentos de tus decisiones, y por qué A y no B es mejor solución en un contexto particular.
BDD y TDD no son mutuamente excluyentes, de hecho, pueden y deben coexistir. Depende principalmente del contexto de lo que quieres construir y testear.
BDD es sobre desarrollo de funcionalidades Test-First. El objetivo no es el cómo sino el qué. El bucle de retroalimentación es largo porque obtendrás el “verde” una vez que la funcionalidad esté implementada y funcionando como se esperaba.
TDD también es otro desarrollo guiado por Test-First pero, a diferencia de BDD, se trata de un bucle de retroalimentación más corto y rápido.
- Primero, especificas lo que quieres. Piensas sobre el diseño de tu clase o método. Su nombre o firma. Sus dependencias. Pero todo esto con pequeños pasos, uno a la vez.
- Segundo, haces que esa pequeña cosa funcione de la manera más simple posible.
- Finalmente, lo haces mejor. Porque el software es lo suficientemente difícil y complicado como para hacerlo bien al primer intento, así que el refactoring es imprescindible para mantener un sistema saludable. En este punto, con un “test verde ejecutándose”, puedes refactorizar y mejorar tu lógica de forma segura.
Lo anterior es básicamente TDD, cierto, pero… ¿qué tiene de especial? El bucle de retroalimentación constante y las decisiones de diseño que necesitas tomar antes de escribir realmente la solución. Este es el poder de TDD.
¿Por qué pasos tan pequeños en TDD?
Teóricamente “debes” escribir pequeños pasos para cada iteración, pero ¿por qué? Se trata del bucle de retroalimentación. Esto depende de ti, tus expectativas y tu experiencia con testing.
