Nexus - AI Task Orchestrator

61-Test
Mantenimiento - Test Zeus

Mantenimiento
Titulo
Descripcion
Contenido Markdown
4003 caracteres
# Mantenimiento - Test Zeus

Test

## Pasos

Preparación y contexto
1.1. Ejecuta la batería actual de tests para tener una línea base (qué pasa hoy).
1.2. Lee docs/TESTING-IMPLEMENTATION-PLAN.md y adopta exactamente sus convenciones (naming, estructura de carpetas, mocks, fixtures, estilo de assertions, etc.).

Inventario de métodos y superficie real de la app
2.1. Recorre todos los proyectos relevantes (API, Application, Domain, Infrastructure, etc.).
2.2. Genera un listado de:

Controladores y endpoints (rutas, verbos, auth, códigos de respuesta esperados).

Servicios/handlers/casos de uso públicos.

Repositorios/adapters y componentes con lógica.
2.3. Clasifica métodos por criticidad:

Alta: reglas de negocio, seguridad, dinero/datos sensibles.

Media: mapeos, validaciones, transformaciones.

Baja: getters simples, wiring, pasarela a dependencias externas sin lógica.

Detección de unit tests faltantes (gap analysis)
3.1. Inspecciona el proyecto de tests y mapea “código → test existente”.
3.2. Para cada método con lógica, marca si faltan tests para:

Camino feliz (happy path).

Validaciones / parámetros inválidos.

Excepciones esperadas (y que el mensaje/tipo sea el correcto si aplica).

Casos límite (nulos, vacíos, límites numéricos/fechas, colecciones).

Branching (ifs/switch) y combinatoria mínima razonable.
3.3. Produce un reporte en markdown: docs/MAINTENANCE-TEST-GAPS.md con tabla:

Clase/Método

Tipo (Controller/Service/Domain/etc.)

Tests existentes

Tests faltantes (lista)

Prioridad (Alta/Media/Baja)

Implementación de unit tests faltantes (según el plan del repo)
4.1. Implementa primero los gaps de prioridad Alta, luego Media, luego Baja.
4.2. Sigue al pie de la letra docs/TESTING-IMPLEMENTATION-PLAN.md:

Patrón Arrange/Act/Assert

Convención de nombres

Estructura por carpetas

Uso de mocks/fakes

Fixtures reutilizables
4.3. Asegura que los tests sean:

Deterministas (sin dependencias de hora real, random sin seed, red, etc.).

Rápidos (sin I/O ni DB real).

Claros (un motivo de fallo por test, assertions relevantes).
4.4. Ejecuta los tests tras cada bloque (por módulo) y no dejes el repo “roto” entre commits.

Cobertura y calidad mínima
5.1. Genera un reporte de cobertura antes/después (si el proyecto ya usa coverage, intégrate; si no, propón y añade Coverlet + ReportGenerator).
5.2. Enfócate en cobertura de lógica, no en inflar números (no tests “de relleno”).
5.3. Identifica código difícil de testear y sugiere refactors pequeños (extraer dependencias, interfaces, separar lógica pura).

Documentación Postman (colección y entorno)
6.1. Descubre todos los endpoints reales:

Preferible: desde Swagger/OpenAPI si existe (Swashbuckle/NSwag).

Alternativa: inspección de controllers + attributes [HttpGet], [Route], etc.
6.2. Crea o actualiza una colección Postman:

Agrupación por recurso (Users, Orders, Auth…)

Nombre, método, URL, descripción, headers, auth.

Ejemplos de request/response (mínimo: éxito + error típico).

Variables (baseUrl, token, etc.).
6.3. Crea/actualiza Environment (local/dev) con variables:

baseUrl

authToken (o flujo para obtenerlo)

ids de ejemplo (userId, orderId, etc.)
6.4. Añade tests básicos en Postman (si aplica):

Status code esperado

Schema básico / campos clave

Tiempo de respuesta (umbral razonable)
6.5. Exporta los artefactos a repo, por ejemplo:

docs/postman/ProjectAPI.postman_collection.json

docs/postman/ProjectAPI.local.postman_environment.json

Validación final
7.1. Ejecuta build + tests + (si procede) coverage en limpio.
7.2. Verifica que la colección Postman funciona contra un entorno levantado localmente.
7.3. Actualiza README o docs/ con:

Cómo ejecutar tests

Cómo generar/ver coverage

Cómo usar la colección Postman

Entrega
8.1. Genera un resumen final en docs/MAINTENANCE-SUMMARY.md:

Qué gaps había y cuántos se cubrieron

Qué métodos quedaron fuera y por qué (si aplica)

Cobertura antes/después

Ubicación de la colección Postman

Recomendaciones de refactor o próximos pasos