TDD vs BDD - Behavior Driven Development (Desarrollo Guiado por Comportamiento)

Test-Driven Development (TDD) es un enfoque de programación que enfatiza la creación de pruebas antes de desarrollar la funcionalidad del código. Este método asegura que el código cumple con los requisitos previstos y ayuda a prevenir errores.

📚 Origen

Test-Driven Development (TDD) fue desarrollado por Kent Beck a fines de la década de 1990 como parte de Extreme Programming.

TDD sigue un ciclo de agregar una prueba, fallar en la ejecución de la prueba, escribir código para pasar la prueba y luego refactorizar el código.

TDD se centra en probar pequeñas unidades de código a la vez, asegurando que el sistema se construya de manera incremental y con una alta cobertura de pruebas.

También conocido como el ciclo 'Red-Green-Refactor', donde se escribe código para hacer pasar la prueba fallida y luego se refactoriza para mejorar su estructura.

BDD (Behavior Driven Development), o Desarrollo Guiado por Comportamiento, es una metodología de desarrollo de software que busca mejorar la colaboración entre equipos técnicos y de negocio definiendo el comportamiento esperado del sistema en lenguaje natural estructurado antes de escribir código.

BDD fue creado por Dan North en 2006 como una evolución de TDD (Test-Driven Development). Mientras que TDD se centra en escribir pruebas unitarias técnicas antes del código, BDD eleva la perspectiva al nivel del comportamiento del usuario y del negocio, utilizando un lenguaje que todos los involucrados pueden entender.

La idea fundamental de BDD es que el software debe definirse en términos de comportamientos deseados expresados mediante ejemplos concretos, no en términos de especificaciones técnicas abstractas. Estos ejemplos, escritos en formato Given-When-Then (Dado-Cuando-Entonces), se convierten simultáneamente en documentación viva, especificación de requisitos y pruebas automatizadas ejecutables.

BDD cierra la brecha de comunicación entre el qué (lo que el negocio necesita) y el cómo (lo que el equipo técnico construye), asegurando que ambos lados compartan la misma comprensión del comportamiento esperado.

BDD se distingue por varios elementos fundamentales:

Formato Given-When-Then

El corazón de BDD es la estructura Given-When-Then para describir comportamientos:

• Given (Dado): establece el contexto o estado previo del sistema.
• When (Cuando): describe la acción o evento que se produce.
• Then (Entonces): define el resultado esperado que debe verificarse.

Feature: Transferencia bancaria Como cliente del banco Quiero transferir dinero entre mis cuentas Para gestionar mis finanzas cómodamente Scenario: Transferencia exitosa con saldo suficiente Given el cliente tiene una cuenta corriente con 1000 EUR And el cliente tiene una cuenta de ahorro con 500 EUR When el cliente transfiere 200 EUR de la cuenta corriente a la cuenta de ahorro Then la cuenta corriente debe tener 800 EUR And la cuenta de ahorro debe tener 700 EUR And se debe registrar la transacción en el historial Scenario: Transferencia rechazada por saldo insuficiente Given el cliente tiene una cuenta corriente con 100 EUR When el cliente intenta transferir 200 EUR de la cuenta corriente Then la transferencia debe ser rechazada And se debe mostrar el mensaje "Saldo insuficiente" And la cuenta corriente debe mantener 100 EUR

Lenguaje Gherkin

Gherkin es el lenguaje formal utilizado para escribir escenarios BDD. Sus características principales son:

• Legible por humanos no técnicos.
• Soporta múltiples idiomas (español, inglés, francés, etc.).
• Estructurado con palabras clave: Feature, Scenario, Given, When, Then, And, But.
• Permite Scenario Outline con tablas de datos para parametrizar pruebas.
• Los archivos tienen extensión .feature.

Las tres amigos (Three Amigos)

BDD promueve sesiones de Three Amigos donde tres perspectivas colaboran para definir comportamientos:

1. Negocio (Product Owner): define qué quiere el usuario y por qué.
2. Desarrollo (Developer): identifica cómo implementar el comportamiento.
3. Testing (QA): identifica casos extremos, errores y escenarios que podrían fallar.

Especificación mediante ejemplos

En lugar de requisitos abstractos como "el sistema debe validar los datos de entrada", BDD utiliza ejemplos concretos:

Scenario Outline: Validación de email When el usuario introduce el email "<email>" Then el sistema debe mostrar "<resultado>" Examples: | email | resultado | | usuario@gmail.com | Email válido | | usuario@ | Email inválido | | @gmail.com | Email inválido | | usuario.com | Email inválido | | user@empresa.co.uk | Email válido |

Veamos el flujo completo de BDD en un proyecto real: el desarrollo de un sistema de descuentos para un e-commerce.

Sesión de Three Amigos:

El Product Owner, un Developer y una QA se reúnen para definir la funcionalidad de cupones de descuento. La conversación se traduce en escenarios:

Feature: Aplicación de cupones de descuento Como comprador en la tienda online Quiero aplicar cupones de descuento a mi carrito Para ahorrar dinero en mis compras Scenario: Cupón de porcentaje válido Given el carrito tiene productos por valor de 100 EUR And existe un cupón "VERANO20" con 20% de descuento When el comprador aplica el cupón "VERANO20" Then el total del carrito debe ser 80 EUR And se debe mostrar "Cupón aplicado: -20 EUR" Scenario: Cupón expirado Given existe un cupón "INVIERNO" que expiró el 2025-12-31 When el comprador intenta aplicar el cupón "INVIERNO" Then el cupón debe ser rechazado And se debe mostrar "Este cupón ha expirado" Scenario: Cupón con importe mínimo no alcanzado Given el carrito tiene productos por valor de 30 EUR And existe un cupón "ENVIOGRATIS" con compra mínima de 50 EUR When el comprador aplica el cupón "ENVIOGRATIS" Then el cupón debe ser rechazado And se debe mostrar "Compra mínima de 50 EUR requerida" Scenario: Solo un cupón por pedido Given el carrito ya tiene aplicado el cupón "VERANO20" When el comprador intenta aplicar otro cupón "FLASH10" Then el segundo cupón debe ser rechazado And se debe mostrar "Solo se permite un cupón por pedido"

Implementación de los Step Definitions (Python + Behave):

from behave import given, when, then @given('el carrito tiene productos por valor de {total:d} EUR') def step_carrito_con_total(context, total): context.carrito = Carrito() context.carrito.agregar_producto(Producto("Item", total)) @given('existe un cupón "{codigo}" con {porcentaje:d}% de descuento') def step_cupon_porcentaje(context, codigo, porcentaje): context.cupones[codigo] = CuponPorcentaje(codigo, porcentaje) @when('el comprador aplica el cupón "{codigo}"') def step_aplicar_cupon(context, codigo): cupon = context.cupones.get(codigo) context.resultado = context.carrito.aplicar_cupon(cupon) @then('el total del carrito debe ser {esperado:d} EUR') def step_verificar_total(context, esperado): assert context.carrito.total == esperado

Ejecución:

$ behave features/cupones.feature Feature: Aplicación de cupones de descuento Scenario: Cupón de porcentaje válido ... passed Scenario: Cupón expirado ... passed Scenario: Cupón con importe mínimo no alcanzado ... passed Scenario: Solo un cupón por pedido ... passed 4 scenarios passed, 0 failed

BDD aporta beneficios significativos al proceso de desarrollo de software:

Comunicación entre silos: el mayor valor de BDD no es técnico, sino comunicativo. Al obligar a los equipos de negocio, desarrollo y QA a sentarse juntos y definir comportamientos en un lenguaje compartido, se eliminan las ambigüedades y malentendidos que son la causa principal de requisitos mal implementados.

Documentación viva: los archivos .feature de BDD sirven simultáneamente como documentación de requisitos y pruebas ejecutables. A diferencia de documentos de Word que quedan obsoletos rápidamente, los escenarios BDD se ejecutan con cada build y fallan si el comportamiento del sistema cambia. La documentación siempre está actualizada porque es código.

Reducción del retrabajo: al definir el comportamiento esperado antes de escribir código, se reducen drásticamente los bugs causados por malentendidos entre negocio y desarrollo. Estudios indican que entre el 40% y el 60% de los defectos de software se originan en requisitos mal comprendidos. BDD ataca directamente esta causa raíz.

Criterios de aceptación claros: los escenarios BDD funcionan como criterios de aceptación verificables. No hay discusión sobre si una funcionalidad "está terminada" o no: si todos los escenarios pasan, la funcionalidad cumple con lo acordado.

Cobertura de casos extremos: la sesión de Three Amigos, con la perspectiva del QA, asegura que se consideren escenarios de error, casos límite y flujos alternativos desde el inicio del diseño, no como hallazgos tardíos durante el testing.

Herramientas BDD por lenguaje

¿Cuál es la diferencia entre BDD y TDD?

TDD escribe pruebas técnicas unitarias antes del código, enfocándose en el diseño interno. BDD escribe escenarios de comportamiento en lenguaje natural antes del código, enfocándose en el valor para el usuario. BDD opera a un nivel de abstracción más alto y es comprensible por personas no técnicas. En la práctica, BDD y TDD son complementarios: BDD para comportamiento externo, TDD para diseño interno.

¿Los escenarios BDD reemplazan las pruebas unitarias?

No. Los escenarios BDD son pruebas de aceptación a nivel de comportamiento del sistema. Las pruebas unitarias verifican el correcto funcionamiento de componentes individuales a nivel técnico. Ambas son necesarias y operan en diferentes niveles de la pirámide de testing.

¿Quién escribe los escenarios BDD?

Idealmente, los escenarios se co-crean en sesiones de Three Amigos. El Product Owner aporta el "qué" y el "por qué", el Developer aporta el "cómo" y el QA aporta los "qué pasa si". La redacción final puede hacerla cualquiera de los tres, pero lo importante es que los tres contribuyan y estén de acuerdo.

¿BDD solo funciona para aplicaciones web?

No. BDD es agnóstico respecto a la tecnología. Se puede aplicar a aplicaciones web, móviles, APIs, sistemas embebidos, microservicios o cualquier tipo de software. Lo que cambia es la implementación de los step definitions, no el enfoque de definir comportamientos.

¿Cuántos escenarios debería tener una Feature?

No hay un número fijo, pero como regla general, una Feature debería tener entre 3 y 10 escenarios. Menos de 3 sugiere que la funcionalidad no está suficientemente explorada. Más de 10 indica que la Feature es demasiado grande y debería dividirse. Los escenarios deben cubrir el flujo principal (happy path), los principales flujos alternativos y los casos de error más relevantes.

¿BDD ralentiza el desarrollo?

A corto plazo, las sesiones de Three Amigos y la escritura de escenarios añaden tiempo al inicio. A medio y largo plazo, BDD ahorra tiempo significativamente al reducir malentendidos, retrabajo, bugs y discusiones sobre si una funcionalidad cumple los requisitos. Los equipos que practican BDD consistentemente reportan menos defectos y mayor velocidad de entrega sostenible.