TDD vs BDD: Test-driven development vs. Behavior-driven development
Hemos hablado recientemente tanto de Test-driven development (TDD) como de Behavior-driven Development (BDD), dos estrategias de desarrollo que tienen sus ventajas y desventajas, pero que se adoptan para diferentes soluciones y están presentes en multitud de proyectos. Hoy comentaremos las principales diferencias y, precisamente, los casos de uso de cada una de ellas, es decir, en qué tipo de desarrollos aplica mejor una metodología que la otra.
Si recordamos, Behavior-driven development es una metodología agile de desarrollo software en la que una aplicación se documenta y diseña en función del comportamiento que los usuarios esperan experimentar al interactuar con ella. Por otro lado, Test-driven development una metodología de programación en la que se escriben primero las pruebas, normalmente unitarias, y después se escribe el código fuente de tal manera que supere dichos tests.
Diferencias entre TDD y BDD y principales aplicaciones de cada metodología
La diferencia clave entre ambos enfoques es el alcance. TDD es una práctica de desarrollo, mientras que BDD es una metodología de equipo. Por tanto, en TDD los desarrolladores escriben las pruebas, y en BDD las especificaciones automatizadas las crean los usuarios o los tester.
Optar por TDD implica una serie de desafíos que afrontar. Por ejemplo, nuestro equipo necesita de un gran conocimiento en el desarrollo de pruebas unitarias. Es básico para ir por esta vía. Además, desde las etapas más tempranas del proyecto es necesario tener totalmente claro hacia dónde va el desarrollo y qué se va a hacer, su alcance y todas sus posibles limitaciones.
Lógicamente, en este escenario las pruebas van a estar enfocadas desde la perspectiva del desarrollador sin tener en cuenta nada más que su propia experiencia y las especificaciones y requisitos iniciales. Con este enfoque no se evalúa la calidad de la integración del producto. La parte buena de optar por TDD es que el nivel técnico, la calidad del producto en este sentido, es elevada. Se dispone de gran cobertura de pruebas unitarias antes de comenzar el desarrollo. Los cambios, por otro lado, se detectan porque las pruebas diseñadas fallarán.
Si nos fijamos en BDD, su característica principal es que las pruebas se pueden escribir en un lenguaje común o de negocio mediante lenguajes especiales como Gherkin, por ejemplo, a la vez que se describe el flujo del usuario por la aplicación. También se define de esta manera el comportamiento del sistema como respuesta a las interacciones.
Gherkin, por cierto, es un Lenguaje Específico de Dominio (DSL) y está diseñado para resolver un problema muy específico como lo es la comunicación entre los perfiles de negocio y los perfiles técnicos, sin duda la herramienta definitiva para lograr que funcione este enfoque de desarrollo. Gracias a este tipo de lenguajes, con el enfoque BDD no es necesario que los equipos de negocio tengan conocimientos técnicos avanzados ni pruebas unitarias. Las instrucciones se dan en un lenguaje cercano al natural, intuitivo y fácil de asumir, y se hacen a través de la fórmula GIVEN, WHEN, THEN:
- GIVEN: se describen las precondiciones necesarias para la ejecución del escenario.
- WHEN: se narran las acciones que hará el usuario en el sistema.
- THEN: se escriben las respuestas esperadas del sistema o validaciones.
Bien, ¿pero qué enfoque elegir?
Antes comentamos que, aunque ambas aproximaciones parezcan similares, la diferencia principal entre ambas está en el alcance. En TDD, es el equipo de desarrollo quien escribe los tests, mientras que en BDD es el usuario final (junto al resto del equipo, sí, pero iniciado por ese usuario) quien determina por dónde ha de ir el desarrollo. El comportamiento de la aplicación es la idea central de BDD; se centra en el cliente y fuerza a desarrolladores y probadores a ponerse en su lugar. Si las acciones no afectan al usuario final, es posible que BDD no represente muy bien ese escenario; en ese caso, TDD sería la elección más indicada.
Como sucede con muchas otras prácticas de desarrollo de software, no suele ser factible identificar qué es lo que funciona en general para todos los proyectos. Para los sistemas que se rigen por las acciones del usuario final, como una tienda online o un sistema de recursos humanos, BDD es la mejor manera de capturar todas las acciones del usuario. Para los sistemas que tienen llamadas a API de terceros, cron jobs, o exportaciones/importaciones de datos, TDD será la mejor solución.
Describir y entender a la perfección las necesidades de un sistema tiene muchos beneficios que van más allá de lo correcto, o no, que sea el código. La mejor baza para generar productos de calidad está en el diálogo interdepartamental, que se debería plantear para asegurar que las inquietudes y objetivos de cada parte queden satisfechas.
Jefe de Capacitación para Soluciones Cloud, posee una amplia experiencia en áreas comerciales y técnicas a nivel nacional e internacional. Con una base en Ingeniería de Telecomunicaciones y un MBA, destaca en el desarrollo de negocios, especialmente con grandes cuentas y partners en sectores tanto privados como públicos.