De Gherkin a Código

El flujo de trabajo de Gherkin a código comienza con un escenario fallido, implementa definiciones de pasos mínimas y luego construye el código de la aplicación hasta que el escenario pasa. Esto es desarrollo "outside-in" con criterios de aceptación ejecutables.

Receta

1. Escribir escenario (falla - sin pasos)
2. Implementar "stubs" de pasos (falla - NotImplementedError)
3. Construir código de aplicación (el escenario pasa)
4. Refactorizar pasos y aplicación conjuntamente

Cuándo usar esto:

• Nueva funcionalidad con criterios de aceptación claros
• El equipo practica BDD como disciplina de diseño
• Los interesados revisan los escenarios antes de la implementación

Ejemplo de Trabajo

# features/discount.feature
Feature: Volume discount
  Scenario: 10% discount for orders over 1000
    Given a customer with a cart total of 1500.00
    When the discount is calculated
    Then the discount amount is 150.00
    And the final total is 1350.00

# Paso 1: pasos fallidos
from pytest_bdd import scenarios, given, when, then, parsers
 
scenarios("../discount.feature")
_cart = {}
 
@given(parsers.parse("un cliente con un total de carrito de {total:f}"))
def cart_total(total):
    _cart["total"] = total
 
@when("se calcula el descuento")
def calculate():
    from myapp.discount import apply_volume_discount
    _cart["result"] = apply_volume_discount(_cart["total"])
 
@then(parsers.parse("el monto del descuento es {amount:f}"))
def check_discount(amount):
    assert _cart["result"]["discount"] == amount
 
@then(parsers.parse("el total final es {total:f}"))
def check_final(total):
    assert _cart["result"]["final"] == total

# Paso 2: código de aplicación mínimo
def apply_volume_discount(total: float) -> dict[str, float]:
    if total > 1000:
        discount = total * 0.10
    else:
        discount = 0.0
    return {"discount": discount, "final": total - discount}

Lo que esto demuestra:

• El escenario impulsa lo que se debe construir
• Los pasos son una conexión delgada sobre apply_volume_discount
• El código de la aplicación es la implementación más pequeña para pasar
• Refactorizar después de que esté en verde

Análisis Profundo

Flujo "Outside-In"

Escenario (aceptación)
  -> Definiciones de pasos (conexión)
    -> Función de servicio (dominio)
      -> Pruebas unitarias (casos límite)

Cuándo Añadir Pruebas Unitarias

• Después de que el escenario pase, añadir pruebas unitarias de pytest para casos límite (0, límite de 1000, negativos)
• Los escenarios cubren las rutas felices; las pruebas unitarias cubren los límites y errores

Trampas Comunes

• Implementar todo en los pasos - monolito no testeable en el archivo de pasos. Solución: extraer a módulos myapp/ inmediatamente.
• Escribir todos los escenarios por adelantado - BDD en cascada. Solución: un escenario por historia; iterar.
• Omitir la fase de pasos fallidos - en verde sin verificación. Solución: ejecutar el escenario, confirmar que falla por la razón correcta.
• Escenario demasiado detallado - "Dado que existe la fila 42 de la base de datos". Solución: lenguaje de dominio: "Dado un cliente premium."
• Sin pruebas unitarias después de BDD - lagunas en los límites. Solución: BDD + pruebas unitarias de pytest se complementan.

Alternativas

Preguntas Frecuentes

Relacionado

• Definiciones de Pasos - escribir pasos
• Sintaxis de Gherkin - autoría de escenarios
• Aserciones y Estructura de Pruebas - complemento de pruebas unitarias
• Mejores Prácticas de BDD - mantenimiento

Versiones de Stack: Esta página fue escrita para Python 3.14.0, FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, y uv 0.6+.