dev-python-testinglisted

# Convenciones de testing en Python La **cobertura mínima objetivo** de este proyecto está en **Python → Cobertura mínima objetivo** de `.claude/context/00_perfil_proyecto.md`. Es un campo **sin default seguro**: si sigue sin rellenar, pregunta al humano antes de dar por buena una cifra — no la asumas. Las convenciones del código bajo test (uv, layout, tipado, docstrings) están en `dev-python-coding`. ## Framework y estructura - Framework: **pytest**. No uses `unittest` para tests nuevos, aunque el módulo bajo test lo importe. - `tests/` refleja la estructura de `src/[paquete]/`: a `src/[paquete]/servicios/pedidos.py` le corresponde `tests/servicios/test_pedidos.py`. - Un fichero de test por módulo. Si un fichero de test crece hasta ser inmanejable, la señal suele ser que el módulo bajo test hace demasiadas cosas — dilo en vez de partir el test en dos a ciegas. - Fixtures compartidas en el `conftest.py` del nivel más bajo que las necesite, no en la raíz por defecto. ## Comando ```bash uv run pytest -q ``` Corre también automáticamente en el hook `Stop` (`.claude/hooks/stop_run_tests.sh`), así que verás el resultado antes de dar cualquier tarea por cerrada. Un `Stop` en rojo no se ignora. ## Mockeo de dependencias externas - **Las conexiones a base de datos se mockean siempre** en los tests unitarios. Un test unitario nunca abre una conexión real ni depende de que haya una BD levantada. - Lo mismo aplica a llamadas HTTP salientes, sistema de ficheros fuera de