Behavior-Driven Development
El Behavior-Driven Development (BDD, desarrollo guiado por comportamiento) es una extensión de Test-Driven Development que traslada el foco de las pruebas técnicas al comportamiento esperado del sistema desde la perspectiva del usuario de negocio. Las pruebas se escriben en lenguaje natural estructurado —comprensible para personas no técnicas— antes de que el código exista, siguiendo el formato Given/When/Then (dado/cuando/entonces).
Dan North acuñó el término en 2003 como evolución de TDD, observando que el principal problema de TDD no era técnico sino de comunicación: los desarrolladores no sabían qué cosas probar, y los tests técnicos no eran legibles para los stakeholders de negocio.
El formato Given/When/Then
BDD estructura cada escenario de comportamiento en tres cláusulas:
- Given (dado): el estado inicial del sistema o el contexto en el que ocurre la acción.
- When (cuando): la acción que realiza el usuario o el sistema.
- Then (entonces): el resultado esperado que puede verificarse.
Ejemplo:
Given que el usuario ha iniciado sesión y tiene saldo suficiente,
When transfiere 100€ a otra cuenta,
Then su saldo se reduce en 100€ y la transacción aparece en el historial.
Este escenario puede ser escrito por el propietario del producto o el analista de negocio, revisado por el equipo técnico y ejecutado automáticamente por una herramienta de BDD como Cucumber o Behave.
Beneficios
- Lenguaje compartido: los escenarios BDD son comprensibles tanto para stakeholders de negocio como para desarrolladores, reduciendo malentendidos en los criterios de aceptación.
- Documentación viva: los escenarios son a la vez especificación y prueba: cuando el código cambia, las pruebas detectan si el comportamiento esperado también ha cambiado.
- Cobertura orientada al valor: las pruebas BDD se centran en lo que importa al usuario, no en los detalles de implementación técnica.
- Facilita el SDD: los escenarios Given/When/Then son una forma de spec legible tanto por personas como por agentes de IA.
BDD y la IA
BDD tiene una sinergia directa con el desarrollo asistido por IA:
- Los escenarios Given/When/Then pueden usarse como especificación para que un agente de IA genere el código que los satisface: la prueba precede al código, tal como prescribe TDD.
- Los escenarios escritos por el equipo en lenguaje natural son más resistentes a las alucinaciones que las specs puramente técnicas, porque están anclados en comportamientos de usuario verificables.
- Las herramientas de IA pueden ayudar a transformar historias de usuario en escenarios BDD, aunque la revisión humana de la cobertura de casos extremos sigue siendo imprescindible.
Error frecuente
Usar BDD solo como herramienta técnica de testing, ignorando el lenguaje compartido. El valor de BDD no está en Cucumber o Gherkin: está en que las personas de negocio y las técnicas colaboran para definir el comportamiento antes de construirlo. Si los escenarios Given/When/Then los escribe solo el equipo técnico sin participación del propietario del producto o los usuarios, BDD se convierte en TDD con sintaxis diferente.
Recursos
📄 Scrum Master en equipos con IA v.1.0Descarga gratuita · Scrum Manager
Referencias
- North, Dan. (2006). "Introducing BDD". dannorth.net.
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.