METODOLOGÍA

BDD

Behavior-Driven Development

Escribe los tests en un lenguaje que el stakeholder de negocio pueda leer. Luego haz que esos tests pasen.

Última revisión: 2026-05-24 porKevin Riedl wiki ↗

Behavior-Driven Development es TDD con el lenguaje de los tests reescrito para que lo lean no-ingenieros. Herramientas como Cucumber usan un formato Given/When/Then que un product manager puede firmar. La idea es mantener los tests alineados con el comportamiento de negocio que validan, no con la implementación que existe hoy.

En la práctica el valor es máximo en las capas de integración y aceptación, donde la barrera de lenguaje entre ingeniería y producto produce bugs reales. En la capa de unit tests, BDD añade más ceremonia de la que ahorra.

// FAQ

Preguntas frecuentes

Preguntas frecuentes

No son alternativas. BDD es TDD reescrito para que lo lea negocio. Donde el producto firma criterios de aceptación, BDD ayuda. Donde el comportamiento es interno (algoritmos, servicios, infraestructura), añadir Given/When/Then es solo más ceremonia. Mezclar capas también es válido.
Cuando el PM deja de leerlo. Los escenarios Given/When/Then que nadie del lado de negocio revisa son tests normales con sintaxis verbosa y ningún beneficio. La señal: si en tres meses ningún stakeholder ha tocado los .feature, mátalo y vuelve a asserts directos.
Rara vez. Antes de tener un PM dedicado o un dominio que estabilizó vocabulario con negocio, BDD es solución buscando problema. En las tempranas, una conversación de cinco minutos sustituye la documentación que BDD codifica. Adóptalo cuando el cuello de botella sea el ancho de banda entre producto e ingeniería, no antes.