BDD (Behavior Driven Development) sirve cuando el comportamiento del sistema tiene que quedar claro para más de un rol. No es un formato universal para cualquier test.
Cuándo SÍ usar BDD
Úsalo cuando la pregunta central es: cómo debería comportarse el sistema desde negocio.
- Reglas de negocio y validaciones con impacto funcional.
- Flujos de usuario y journeys end-to-end.
- Requisitos ambiguos que necesitan ejemplos concretos.
- Contextos donde QA, dev, análisis y producto leen lo mismo.
Ejemplo de BDD bien aplicado:
Escenario: Transferencia entre cuentas válida
Dado que el cliente tiene saldo suficiente
Cuando realiza una transferencia de $1000
Entonces el saldo se debita correctamente
Esto describe comportamiento de negocio, no una llamada técnica.
Cuándo NO usar BDD
No lo uses para test técnico aislado. Ahí BDD se vuelve overhead.
- Parsing, serialización, utilidades y lógica matemática.
- Repositorios, validaciones internas o detalles de implementación.
- Wrappers de endpoint tipo “pega 200”.
- Matrices combinatorias enormes que nadie fuera de QA va a leer.
Ejemplo de anti-patrón:
Escenario: Obtener cliente
Dado que llamo al endpoint /cliente
Cuando ejecuto el request
Entonces responde 200
Eso no expresa comportamiento de negocio; es un API test disfrazado.
Smells frecuentes de BDD mal usado
- Feature como wrapper de API: habla de request, endpoint, status y payload.
- Steps que son código disfrazado: describen implementación, no resultado.
- Features gigantes: cientos de escenarios técnicos sin valor de comunicación.
- Nadie lee los .feature: si negocio y dev no participan, BDD perdió sentido.
Regla práctica
Si el escenario responde: “qué hace el sistema para el usuario”, vas bien.
Si responde: “cómo testeo esta API/método/clase”, probablemente no es BDD.
Patrón que mejor funciona
- BDD para reglas de negocio y flujos.
- API tests para contratos y validaciones técnicas.
- Unit tests para lógica interna.
Cada cosa en su lugar. Cuando mezclas todo en BDD, el framework se infla y el valor cae.