TDD vs BDD vs ATDD: cuándo usar cada uno
No son rivales sino capas distintas: TDD guía el diseño del código, BDD alinea el entendimiento del negocio y ATDD formaliza criterios de aceptación. La elección depende del problema que resuelves.
Pregunta: ¿Debo adoptar TDD, BDD o ATDD en mi equipo?
| Criterio | TDD | BDD | ATDD |
|---|---|---|---|
| Quién es la audiencia | Desarrolladores | Negocio + QA + Dev (Three Amigos) | Equipo + Product Owner |
| Qué optimiza | Diseño y feedback rápido | Comunicación y documentación viva | Criterios de aceptación claros |
| Nivel de prueba típico | Unitario | Aceptación / integración | Aceptación |
| Coste de adopción | Medio (disciplina individual) | Alto (colaboración + tooling) | Medio |
| Mejor cuando… | El reto es la calidad y el diseño interno del código (un dev disciplinado). | El reto es el entendimiento compartido entre negocio y técnica. | El reto es formalizar criterios de aceptación ejecutables. |
El error de marco
La pregunta “¿TDD o BDD?” suele estar mal planteada: asume que compiten. En realidad responden a dolores distintos.
Regla práctica
- ¿El código es difícil de cambiar y se rompe seguido? → TDD.
- ¿Negocio y técnica entienden cosas distintas por lo mismo? → BDD.
- ¿Las historias llegan sin criterios de aceptación claros? → ATDD.
Grafo de conocimiento
Complementa a
Evoluciona desde