Mejores Prácticas de Pruebas
Reglas para una suite de pytest que sea rápida, confiable y mantenible.
Cómo Usar Esta Lista
- Aplica al escribir nuevas pruebas o al revisar PRs
- Prioriza el aislamiento y la velocidad antes que el porcentaje de cobertura
- Revisa al añadir pruebas de integración o E2E
A - Diseño de Pruebas
- Un comportamiento por prueba. Cada prueba falla por una única razón.
- Estructura de organizar-actuar-afirmar. Legible sin comentarios que expliquen la disposición.
- Nombres descriptivos de pruebas.
test_discount_over_100_raises, notest_discount_3. - Prueba el comportamiento, no la implementación. Afirma salidas y API pública, no llamadas internas.
B - Aislamiento y Velocidad
- Sin red en pruebas unitarias. Mockea HTTP, DNS y APIs externas.
- Estado de base de datos fresco por prueba. Revierte transacciones o usa SQLite en memoria.
- No usar sleep() para temporización. Usa mocks para el tiempo o espera basada en eventos.
- Marca pruebas lentas.
@pytest.mark.slowexcluido de la ejecución por defecto de CI.
C - Fixtures y Datos
- Configuración compartida en fixtures, no copiar-pegar.
conftest.pypara reutilización. - Fixtures de fábrica para datos flexibles.
user_factory(email="...")sobre diccionarios estáticos. - Ámbito de función por defecto. Ámbitos más amplios solo para configuración costosa e inmutable.
- Parametriza casos conocidos; Hypothesis para exploración. No uses bucles dentro de las pruebas.
D - CI y Cobertura
- pytest se ejecuta en cada PR. Verificación requerida, no opcional.
- Cobertura solo en
src/. Piso de 80%; más alto para módulos de autenticación y facturación. - Cobertura de ramas habilitada.
branch = trueen la configuración de cobertura. - Matriz multiversión para bibliotecas. Prueba los límites de
requires-pythoncon nox o matriz de CI.
E - Mantenimiento
- Elimina pruebas para características eliminadas. Las pruebas muertas ocultan la falta de cobertura.
- Corrige pruebas inestables inmediatamente. Cuarentena con
@pytest.mark.flakysolo como medida temporal. - Mockea en los límites, no en todas partes. Demasiados mocks significan probar mocks.
- Pruebas de integración separadas de las pruebas unitarias. Directorios
tests/unit/ytests/integration/.
Preguntas Frecuentes
¿Qué tan rápidas deben ser las pruebas unitarias?
Suite unitaria completa en menos de 60 segundos. Pruebas individuales en menos de 100ms.
¿Qué proporción de pruebas unitarias a integración?
Aproximadamente 80/20. La mayoría de las pruebas son unitarias; la integración cubre rutas críticas.
¿Debo probar funciones privadas?
Prueba a través de la API pública. Los ayudantes privados se cubren indirectamente.
¿Cómo manejo los archivos de datos de prueba?
tests/fixtures/data/ con ruta a través de pathlib.Path(__file__).parent.
¿Pruebas de snapshot?
Útiles para serializadores y plantillas. Revisa las actualizaciones de snapshot cuidadosamente en los PRs.
¿Cuántas afirmaciones por prueba?
Un comportamiento lógico. Múltiples afirmaciones están bien si verifican un único resultado.
¿Las pruebas deben usar HTTP real?
Unitarias: no. Integración/staging: sí contra el entorno de prueba.
¿Cómo pruebo el logging?
Fixture caplog: with caplog.at_level(logging.ERROR):.
¿Pruebas en paralelo?
pytest-xdist -n auto para suites grandes. Asegura primero el aislamiento de las pruebas.
¿Cuándo omitir una prueba?
@pytest.mark.skip con razón para trabajo específico de plataforma o incompleto. No para pruebas fallidas.
Relacionado
- Configuración de pytest - configuración
- Afirmaciones y Estructura de Pruebas - diseño de pruebas
- Cobertura e Informes - política de cobertura
- Mocking y Patching - límites de aislamiento
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+.