Lista de verificación de decisiones BDD
Utiliza esta lista de verificación para decidir si el Desarrollo Guiado por Comportamiento (BDD) con archivos de características Gherkin aporta valor sobre pytest simple para tu proyecto.
Cómo usar esta lista de verificación
- Revísala antes de adoptar BDD para una nueva característica o equipo.
- Puntuación de cada sección: si la mayoría de los elementos están sin marcar, quédate con pytest.
- Vuelve a visitarla cuando los stakeholders soliciten "documentación viva".
Alineación de stakeholders
- Los stakeholders no técnicos leerán los archivos de características. El equipo de producto, QA o analistas de negocio participarán en la revisión de escenarios.
- Los escenarios describen el comportamiento del negocio, no clics en la interfaz de usuario. "El usuario recibe un correo electrónico de confirmación", no "El usuario hace clic en el botón #3".
- El equipo está de acuerdo con el vocabulario Given-When-Then. Lenguaje compartido entre negocio e ingeniería.
- Los criterios de aceptación ya están escritos en forma de escenario. BDD formaliza la práctica existente, no la inventa.
Ajuste técnico
- Las características se mapean a resultados visibles para el usuario. Contratos de API, flujos de trabajo o reglas de dominio, no refactorizaciones internas.
- La configuración de datos de prueba es manejable en las definiciones de pasos. Una configuración compleja puede indicar que las pruebas unitarias son mejores.
- Las definiciones de pasos se mantienen DRY (Don't Repeat Yourself). Pasos reutilizables en diferentes características sin copiar y pegar.
- La CI puede ejecutar la suite BDD en menos de 5 minutos. Las suites BDD lentas se omiten.
Costo-Beneficio
- Existe un presupuesto de mantenimiento para los archivos de características. Los escenarios se desvían sin propiedad.
- pytest por sí solo no puede expresar el comportamiento claramente. BDD añade legibilidad, no solo estructura.
- El tamaño del equipo soporta la sobrecarga. Los equipos pequeños pueden encontrar suficiente pytest con nombres de prueba descriptivos.
- La documentación viva es un objetivo declarado. No solo pruebas, sino documentación que se mantiene actualizada.
Señales de alerta (NO adoptes BDD si)
- Solo los desarrolladores leerán las pruebas. Usa pytest con nombres descriptivos en su lugar.
- Los escenarios duplicarían las pruebas de pytest 1:1. Dos suites para mantener sin beneficio.
- Las definiciones de pasos se convierten en una segunda aplicación. Más lógica en los pasos que en el código de producción.
- Los escenarios inestables erosionan la confianza. Los stakeholders dejan de leer los archivos de características.
Preguntas frecuentes
¿Cuándo es suficiente pytest simple?
Cuando solo los desarrolladores leen las pruebas y el comportamiento es lógica a nivel de unidad, no flujos de trabajo visibles para el usuario.
¿Puedo usar BDD para APIs?
Sí. Los escenarios describen el comportamiento de solicitud/respuesta HTTP. Es una buena opción para pruebas de contrato con stakeholders.
¿behave o pytest-bdd?
behave: ejecutor BDD independiente. pytest-bdd: características Gherkin dentro de pytest. Prefiere pytest-bdd si ya usas pytest.
¿Cuántos escenarios se necesitan para que BDD compense?
Aproximadamente 10+ escenarios de aceptación con participación de stakeholders. Por debajo de eso, pytest es suficiente.
¿Puedo mezclar BDD y pytest?
Sí. BDD para pruebas de aceptación; pytest para unitarias e integración. La mayoría de los proyectos deberían hacerlo.
¿Qué pasa si los escenarios se vuelven largos?
Divídelos en escenarios más pequeños o usa Scenario Outline. Los escenarios largos son un indicio de mal diseño.
¿Es BDD lo mismo que testing?
BDD comenzó como una práctica de diseño. La suite de pruebas es un subproducto de la especificación del comportamiento.
¿Cómo hago una prueba piloto de BDD?
Un archivo de características para el próximo épico. Evalúa el costo de mantenimiento después de un sprint.
¿BDD reemplaza las pruebas unitarias?
No. BDD cubre el comportamiento de aceptación. Las pruebas unitarias cubren la lógica, casos extremos y rutas de error.
¿Qué pasa con Cucumber?
Cucumber es el equivalente en el ecosistema JVM/JS. Python usa behave o pytest-bdd.
Relacionado
- Sintaxis Gherkin - cómo escribir archivos de características
- Configuración de behave / pytest-bdd - configuración de herramientas
- Mejores prácticas BDD - mantenimiento de escenarios
- Mejores prácticas de testing - convenciones de pytest
Versiones de la pila: 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+.