Mejores Prácticas de BDD
Reglas para suites de BDD que se mantienen legibles para los stakeholders y mantenibles para los desarrolladores.
Cómo Usar Esta Lista
- Aplica al escribir o revisar archivos de características y definiciones de pasos.
- Si la mayoría de los elementos están sin marcar, considera seguir usando pytest.
- Revisa el inventario de escenarios trimestralmente para detectar características obsoletas.
A - Calidad de Escenarios
- Los escenarios describen el comportamiento, no la implementación. "Se crea la factura" no "POST /api/v2/invoices devuelve 201".
- Máximo 5-7 pasos por escenario. Escenarios más largos se dividen en múltiples casos.
- Pasos
Givendeclarativos. "Dado un cliente premium" no "Dado que inserto una fila en la tabla de clientes". - Un resultado por escenario. Múltiples afirmaciones
Thenestán bien si verifican un solo comportamiento.
B - Definiciones de Pasos
- Los pasos son pegamento ligero. La lógica de negocio reside en los módulos de la aplicación.
- Reutiliza pasos comunes. Pasos de autenticación, cliente API y aserción compartidos entre características.
- Analizadores tipados para parámetros.
{amount:f}no análisis de cadenas en el cuerpo del paso. - Contexto fresco por escenario. Sin fugas de estado entre ejecuciones.
C - Organización
- Archivos de características agrupados por capacidad.
features/billing/,features/auth/. - Etiquetas para smoke, slow y wip. CI ejecuta smoke en PR; suite completa en main.
-
Scenario Outlinesolo para variaciones de datos. No para casos de prueba no relacionados. -
Backgroundpara configuración compartida. Evita repetirGivenen cada escenario.
D - Proceso
- Escenarios escritos antes de la implementación. BDD de afuera hacia adentro, no pruebas retroactivas.
- Los stakeholders revisan los archivos de características. La documentación viva se mantiene actualizada.
- Las pruebas unitarias complementan BDD. Casos extremos y rutas de error en pytest.
- Elimina escenarios para características eliminadas. Los escenarios obsoletos erosionan la confianza.
E - CI y Mantenimiento
- BDD se ejecuta en CI. Smoke en PR; aceptación completa en main o nocturna.
- Se prefiere la prueba en proceso.
TestClientsobre la conexión a APIs de staging en CI. - Escenarios inestables corregidos o puestos en cuarentena.
@wipexcluidos hasta que sean estables. - Informes publicados como artefactos. Informes HTML/Cucumber para visibilidad de los stakeholders.
Preguntas Frecuentes
¿Cómo se diferencia BDD de las pruebas de integración?
Los escenarios BDD son especificaciones de aceptación legibles por los stakeholders. Las pruebas de integración están enfocadas en los desarrolladores.
¿Cuántos archivos de características?
Uno por área de capacidad. 5-15 escenarios por archivo.
¿Deben los desarrolladores escribir Gherkin?
Desarrolladores + producto juntos. Los desarrolladores son dueños de las definiciones de pasos.
¿Cómo evito la explosión de pasos?
Parametriza los pasos. Revisa el inventario de pasos mensualmente; fusiona duplicados.
¿Solo en inglés?
Las palabras clave de Gherkin están en inglés. El texto de los pasos puede usar el lenguaje del dominio acordado por el equipo.
¿Cómo manejo el versionado de API en los pasos?
Oculta la versión en las definiciones de pasos. Los escenarios permanecen agnósticos a la versión.
¿Puede BDD probar requisitos no funcionales?
Limitado. El rendimiento y la seguridad se adaptan mejor a herramientas dedicadas. BDD para comportamiento funcional.
¿Cómo incorporo nuevos escenarios?
Copia el archivo de características más cercano. Sigue las convenciones de nomenclatura y reutilización de pasos.
¿Qué pasa con BDD para aplicaciones móviles?
Usa pasos en lenguaje de dominio. Los detalles de la UI se ocultan en la capa de definición de pasos (Appium, etc.).
¿Cuándo retirar BDD?
Si los stakeholders dejan de leer los escenarios y el costo de mantenimiento excede el valor, consolida a pytest.
Relacionado
- Lista de Verificación de Decisiones de BDD - criterios de adopción
- Sintaxis de Gherkin - escritura de escenarios
- Pipeline de CI de Gherkin a CI - automatización
- Mejores Prácticas de Pruebas - complemento de pytest
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+.