BDD

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.

Ejemplo de dónde esto de verdad paga: un producto de seguros tiene una regla por la que una reclamación de menos de 30 días con una póliza válida se aprueba automáticamente. Escrito como escenario Gherkin («Dada una póliza activa durante 30 días, Cuando se presenta una reclamación dentro de la ventana de cobertura, Entonces se aprueba automáticamente»), el product owner y el revisor de compliance pueden leerlo, confirmar que coincide con la regla real y atrapar el off-by-one antes de que se envíe. Esa verificación en lenguaje compartido es todo el valor de BDD, y vive en la capa de aceptación e integración donde la brecha entre lo que producto quiso decir y lo que ingeniería construyó es donde nacen los bugs.

Hay también un coste de mantenimiento que los equipos descubren tarde. Los escenarios Gherkin se apoyan sobre una capa de «step definitions», código pegamento que mapea cada línea en lenguaje plano a acciones de test reales. Ese pegamento es software real que hay que mantener en sincronía a medida que el producto cambia, y una suite BDD grande con step definitions descuidadas se vuelve su propia carga de mantenimiento, lenta de correr y frágil de editar. El beneficio (un stakeholder puede leer y firmar el comportamiento) solo paga ese overhead cuando un stakeholder de verdad los lee. Si el Gherkin lo escriben ingenieros, lo leen ingenieros y nadie más lo ve nunca, estás pagando por una capa de traducción sin audiencia.

El trade-off honesto y el error común: BDD no sustituye a TDD, es una capa encima, y aplicarlo en todas partes es el error. Escribir «Dados dos números, Cuando los sumo, Entonces obtengo la suma» para una función trivial es ceremonia que ningún stakeholder de negocio leerá jamás. Reserva Gherkin para los tests que un no-ingeniero genuinamente necesita firmar, y usa tests unitarios planos por debajo de esa línea. Como todas estas prácticas, BDD es una etapa dentro de un SDLC sensato y una herramienta para un problema real de comunicación, no un proceso a adoptar por sí mismo.