El debate TDD vs BDD a menudo se plantea como la elección de un bando. En realidad, responden a preguntas diferentes. El desarrollo basado en pruebas pregunta si el código hace lo que pretendía el desarrollador, mientras que el desarrollo basado en comportamiento pregunta si el equipo está de acuerdo sobre lo que el software debería hacer.

Para concretar la diferencia, creamos una pequeña función de descuento con cada enfoque. Ejecutamos el código en Python 3.13, usando la biblioteca estándar, y los resultados a continuación provienen de esa ejecución. La parte BDD utiliza un pequeño corredor propio para mostrar el mecanismo, por lo que un proyecto real usaría una herramienta como Cucumber o se comportaría en su lugar.

La respuesta corta

El desarrollo basado en pruebas (TDD) es una práctica de codificación. Escribe una pequeña prueba fallida, la hace pasar con el código más simple y luego mejora el diseño. Las pruebas están escritas en código y principalmente por desarrolladores. Kent Beck popularizó la práctica.

El desarrollo impulsado por el comportamiento (BDD) es una práctica de colaboración que surgió de TDD, y Dan North introdujo el término. Los desarrolladores, evaluadores y empresarios se ponen de acuerdo sobre ejemplos de cómo debería comportarse el sistema, escritos en un lenguaje sencillo, y esos ejemplos pueden luego automatizarse.

TDD vs BDD uno al lado del otro

la característica

Esta es la regla comercial que implementaremos: Los pedidos de 1000 o más obtienen un 10 % de descuento. Los miembros obtienen un 5 % de descuento adicional en esos pedidos.

Esto puede parecer claro, pero ya es ambiguo. ¿Un miembro que gasta 500 obtiene un 5 % de descuento? La frase dice “esas órdenes”, por lo que suponemos que no. Tenga esto en cuenta, porque este es exactamente el tipo de pregunta que BDD está diseñado para plantear tempranamente.

Construyéndolo con TDD

TDD sigue un bucle corto conocido como rojo, verde, refactor:

Estas son nuestras pruebas, con una para cada regla:

class DiscountTests(unittest.TestCase):
    def test_no_discount_below_1000(self):
        self.assertEqual(discount(999, False), 0)

    def test_ten_percent_from_1000(self):
        self.assertEqual(discount(1000, False), 100)

    def test_member_gets_extra_five_percent(self):
        self.assertEqual(discount(1000, True), 150)

Luego escribimos el código en tres etapas, ejecutando las pruebas después de cada una. Una sesión TDD estricta agrega una prueba a la vez y esto muestra la misma progresión:

Etapa 1: lo más sencillo

def discount(total, is_member):
    return 0

# 3 tests, 2 failed
#   test_member_gets_extra_five_percent
#   test_ten_percent_from_1000

Devolver cero parece una tontería, pero demuestra que las pruebas en realidad pueden fallar, y la única prueba que pasa es la regla de “sin descuento”.

Etapa 2: agregar el umbral

def discount(total, is_member):
    if total >= 1000:
        return total * 0.1
    return 0

# 3 tests, 1 failed
#   test_member_gets_extra_five_percent

Etapa 3: agregar miembros y limpiar

def discount(total, is_member):
    rate = 0.1 if total >= 1000 else 0
    if is_member:
        rate += 0.05
    return round(total * rate, 2)

# 3 tests, 0 failed

Pasan los tres. Pero lea atentamente esta versión. Le da a un miembro que gaste 500 un descuento del 5%, que no es lo que asumimos que significaba la regla. Ninguna prueba cubrió ese caso, por lo que nada lo marcó. TDD solo protege el comportamiento que pensaba probar. Esa es una limitación real, y la razón por la que las conversaciones sobre ejemplos son tan importantes.

Por qué es importante el ciclo

• El rojo demuestra que la prueba funciona. Una prueba que nunca ha fallado podría no estar probando nada.
• El color verde te mantiene concentrado. Escribes solo el código necesario, lo que ayuda a evitar el exceso de ingeniería.
• Refactor mantiene alta la calidad. Las pruebas le brindan la confianza para cambiar el diseño de forma segura.
• Influye en el diseño. El código que es difícil de probar suele estar demasiado estrechamente acoplado y se nota de inmediato.

Nuestro tutorial de pytest muestra una forma más conveniente de escribir pruebas como estas y el análisis de valores límite explica por qué elegimos 999 y 1000 como valores.

Construyéndolo con BDD

BDD comienza con una conversación, no con herramientas. A menudo se trata de una reunión breve conocida como los tres amigos, en la que una persona del producto, un desarrollador y un evaluador discuten ejemplos concretos:

Tester:  What about a member spending 500?
Product: Good question. No discount. It has to reach 1000 first.
Dev:     And exactly 1000 counts?
Product: Yes, 1000 or more.

Ese intercambio habría detectado el problema en nuestro código TDD. Luego registran sus ejemplos en un formato estructurado llamado Gherkin:

Feature: Order discounts

  Scenario: Member reaches the discount threshold
    Given a member with a cart worth 1000
    When they view the amount to pay
    Then the amount to pay is 850

  Scenario: Member below the threshold gets no discount
    Given a member with a cart worth 500
    When they view the amount to pay
    Then the amount to pay is 500

Cualquier miembro del equipo puede leer eso y decir “sí, eso está bien” o “no, eso está mal”. Incluso si nunca lo automatiza, el escenario ya ha realizado un trabajo útil.

Conexión de pasos al código

Las herramientas conectan cada línea en lenguaje sencillo con una función, llamada definición de paso. Para mostrar la idea, escribimos una pequeña versión nosotros mismos y ejecutamos el primer escenario:

@step("a member with a cart worth 1000")
def given(ctx):
    ctx["cart"] = Cart(is_member=True)
    ctx["cart"].add(1000)

@step("they view the amount to pay")
def when(ctx):
    ctx["amount"] = ctx["cart"].payable()

@step("the amount to pay is 850")
def then(ctx):
    assert ctx["amount"] == 850

# ok Given a member with a cart worth 1000
# ok When they view the amount to pay
# ok Then the amount to pay is 850

Las herramientas reales agregan parámetros, de modo que un solo paso pueda coincidir tanto con “1000” como con “500”, además de generar informes. El resultado es documentación viva: una descripción sencilla del sistema que falla estrepitosamente si deja de ser cierta.

Escribir buenos escenarios

Los escenarios que describen clics e ID de campos se interrumpen con cada rediseño y los lectores empresariales dejan de leerlos. Mantenga los detalles de la interfaz de usuario en el código de paso. Estos escenarios son primos cercanos de los ejemplos de caso de prueba frente a escenario de prueba y, a menudo, también se utilizan en pruebas de aceptación del usuario.

Usando ambos juntos

Los dos encajan naturalmente en un flujo de trabajo “de afuera hacia adentro”:

1. El equipo se pone de acuerdo sobre el comportamiento y escribe un escenario BDD. Falla porque todavía no existe nada.
2. Un desarrollador utiliza TDD para construir las unidades pequeñas necesarias.
3. Las pruebas unitarias pasan y, eventualmente, también lo hace el escenario.
4. Todo se ejecuta en su canal de CI/CD.

Mantenga cada uno en el nivel correcto. Debería tener algunos escenarios para comportamientos importantes y muchas pruebas unitarias rápidas para los detalles. Nuestra guía para pruebas unitarias versus pruebas de integración cubre el resto.

Herramientas

Cuando usar cada

TDD encaja bien cuando:

• Está escribiendo lógica compleja, como precios, análisis o permisos.
• Estás arreglando un error, ya que puedes reproducirlo primero con una prueba fallida.
• Estás trabajando en un código que cambiará con frecuencia.

BDD encaja bien cuando:

• Las reglas comerciales son complejas y los malentendidos resultan costosos.
• Las personas no técnicas realmente leerán y discutirán los escenarios.
• Varios equipos necesitan una definición compartida de cómo se comporta algo.

Cualquiera de los dos puede ser excesivo cuando: estás escribiendo un prototipo desechable o explorando una idea técnica poco clara. Muchos desarrolladores primero aumentan y luego reescriben con pruebas. Las herramientas BDD también son una mala inversión si nadie fuera de ingeniería analiza los escenarios. En ese caso, las pruebas simples con buenos nombres son más sencillas.

Errores comunes

• Tratar BDD como una herramienta de prueba. Pepino sin colaboración es solo una forma detallada de escribir pruebas.
• Implementación de pruebas en TDD. Las pruebas vinculadas a detalles privados se interrumpen durante cada refactorización.
• Omitir el paso de refactorización. Pasas pruebas además del código desordenado.
• Escribir pruebas después del código y llamarlo TDD. Eso sigue siendo útil, pero se pierden los comentarios del diseño.
• Escribir demasiados escenarios de interfaz de usuario. Estos se vuelven lentos y poco fiables. Consulte pruebas inestables.
• Buscando cifras de cobertura. Una buena cobertura todavía pasa por alto comportamientos que nadie consideró, como muestra nuestro ejemplo.

Conclusión

TDD le ayuda a crear lo correcto y BDD le ayuda a crear lo correcto. Nuestro ejemplo de descuento mostró ambos lados: el código pasó todas las pruebas, pero una simple conversación reveló una suposición errónea. Pruébelo en su próxima función pequeña. Escriba tres ejemplos concretos con un colega antes de cualquier código y luego constrúyalo una prueba fallida a la vez.

Preguntas frecuentes

sigue aprendiendo