Práctica focalizada · Bloque 3 · Unidad 3.2
EX-B3-04
Validar settings y sustituirlos en tests
Una API publica información operativa desde constantes codificadas. Los tests modifican globals y dependen del orden en que se ejecutan.
Cómo abordarla
Haz visible el árbol y el ciclo de vida
Ejecuta primero el baseline. Después modifica la frontera indicada, escribe una regresión positiva y otra negativa y conserva la salida real.
Evidencia objetivo: OpenAPI conserva sus parámetros, la configuración falla pronto y el recurso se libera tanto en éxito como en error.
Abrir laboratorio de código
1. Descarga y arranca
- Starter de settings por entornoAPI con constantes, tests verdes, matriz vacía y .env.example seguro; sin modelo Settings.
2. Escribe y prueba
- Clasifica cada valor como regla estable, configuración pública o configuración sensible.
- Crea Settings con prefijo explícito, validación y un proveedor cacheado por proceso.
- Sustituye el proveedor en un test y demuestra que el siguiente recupera el comportamiento normal.
- Añade una comprobación que falle al construir Settings si falta audit_channel y documenta cuándo se ejecuta esa validación.
3. Demuestra el comportamiento
- Módulo de configuración, integración y tests.
- Matriz de fuentes y precedencia observada.
- Salida del fallo esperado y evidencia de aislamiento entre tests.
La respuesta principal es tu código y sus pruebas. Usa este espacio solo para anotar la predicción inicial y el resultado observado.
Predicción breve antes de ejecutar
¿Qué valores deben llegar desde el entorno, cuándo deben fallar y cómo puedes probar otro perfil sin editar la ruta ni conservar estado global?
Frontera de configuración
Baseline: GET /runtime devuelve app_name, environment y max_page_size desde constantes; audit_channel es obligatorio pero nunca se expone en la respuesta.Comprueba estas tres cosas
- ¿Qué campo debe ser obligatorio y qué default es seguro?
- ¿Qué prefijo evita colisiones con variables ajenas?
- ¿Qué estado debes restaurar al terminar el test?
Anota predicción, comando ejecutado y diferencia observada; el código vive en tu workspace.
Sin respuesta guardada.
Pistas opcionales
Pista 1 · Dos cachés
- FastAPI reutiliza un nodo dentro de una petición.
- functools.lru_cache conserva el resultado del proveedor entre llamadas del mismo proceso.
Pista 2 · Sustituye la función
- La clave del mapa de overrides es el callable original, no el tipo Settings.
- Limpia el mapa aunque la aserción falle.
Profundización opcional
Modelar configuración externa con pydantic-settings, distinguir caché de proceso y sustituir el proveedor sin contaminar otras pruebas.
Contexto adicional
- Usa BaseSettings desde pydantic_settings y SettingsConfigDict.
- El archivo .env es solo local y no puede entrar en el entregable; publica únicamente .env.example sin valores sensibles.
- No reconstruyas Settings en cada request y no uses monkeypatch sobre la ruta.
Decisiones abiertas
- Puedes validar settings al construir la app o mediante un smoke check de arranque; documenta el momento exacto del fallo.
Cómo revisar tu respuesta
- Los nombres de entorno usan un prefijo propio y los valores se validan con tipos y límites.
- audit_channel es obligatorio, no aparece en respuestas o logs y su ausencia falla de forma explícita.
- El proveedor no relee el entorno en cada petición y la entrega distingue caché de proceso de caché de Depends.
- El test reemplaza get_settings mediante dependency_overrides y restaura el mapa en finally o una fixture equivalente.
- No se publica .env ni un secreto real; .env.example solo contiene nombres o valores ficticios.
Evidencia, revisión y reinicio
- Matriz de fuentes y valores elegidos para local, test y producción simulada.
- Fallo de validación con configuración obligatoria ausente.
- Test con dependency_overrides restaurado después del intento.
Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.
Reinicio: Volver a descomprimir ex-b3-04-settings.zip y eliminar solo el .env local creado para el intento.