docs: añade plan de cobertura de tests
Co-authored-by: aider (openrouter/openai/gpt-5) <aider@aider.chat>pull/1/head
parent
bae6678a0e
commit
731ff715a8
@ -0,0 +1,96 @@
|
||||
# Plan de cobertura de tests (pendientes y prioritarios)
|
||||
|
||||
Este documento recoge huecos relevantes de cobertura detectados al revisar la suite actual. La intención es prevenir regresiones en flujos críticos, no añadir tests por añadir.
|
||||
|
||||
## Áreas de mejora propuestas
|
||||
|
||||
### 1) Comandos y asignaciones
|
||||
- [ ] Creación con menciones en grupos: si el mensaje incluye @menciones (contextInfo.mentionedJid), asignar a esos usuarios:
|
||||
- Normalizar IDs a dígitos.
|
||||
- Evitar duplicados.
|
||||
- Crear usuarios inexistentes (ensureUserExists).
|
||||
- Verificar ACK de creación refleja destinatarios asignados.
|
||||
- [ ] “Tomar” cuando ya hay otro responsable:
|
||||
- Definir contrato: ¿multi-asignación permitida o bloqueo con mensaje (“ya tiene responsable”)? Añadir test y ajustar si aplica.
|
||||
- [ ] “Soltar” con varios responsables:
|
||||
- Verificar que al soltar uno, la tarea no queda “sin responsable” si siguen existiendo otros asignados.
|
||||
|
||||
### 2) WebhookServer
|
||||
- [ ] Integración de menciones: extraer contextInfo.mentionedJid y pasar “mentions” normalizadas a CommandService (end-to-end).
|
||||
- [ ] getMessageText: cubrir videoMessage.caption además de conversation/extendedText/image caption.
|
||||
- [ ] Cuerpo JSON inválido con Content-Type: application/json:
|
||||
- Devolver 400 sin lanzar excepción no controlada.
|
||||
- [ ] /metrics con METRICS_ENABLED=false:
|
||||
- Debe devolver 404 (ya hay test para enabled=true).
|
||||
- [ ] Eventos desconocidos:
|
||||
- Debe responder 200 (o el comportamiento esperado) sin efectos colaterales.
|
||||
|
||||
### 3) TaskService
|
||||
- [ ] ON DELETE CASCADE: borrar una tarea elimina sus asignaciones (task_assignments).
|
||||
- [ ] FK en createTask con group_id inexistente:
|
||||
- Debe fallar por FK (asegura integridad y que las FKs siguen activas).
|
||||
- [ ] Descripciones con caracteres especiales/SQL:
|
||||
- Asegurar persistencia literal usando parámetros (no concatenación) y sin truncado.
|
||||
- [ ] padTaskId:
|
||||
- Formateo con ancho y no truncar IDs largos.
|
||||
|
||||
### 4) GroupSyncService
|
||||
- [ ] fetchGroupMembersFromAPI:
|
||||
- Fallo de red o JSON corrupto ⇒ snapshot vacío y sin romper flujo superior.
|
||||
- [ ] syncGroups:
|
||||
- 200 con contenido no-JSON o estructura inesperada ⇒ error claro y log.
|
||||
- [ ] Caché de grupos activos:
|
||||
- Si hay vencimiento/actualización, test de refresco para evitar caché desfasado.
|
||||
|
||||
### 5) RemindersService
|
||||
- [ ] start/stop:
|
||||
- No arranca en test (ya lo respeta), y cuando retentionDays <= 0 no programa.
|
||||
- [ ] Bordes de horario/TZ:
|
||||
- Exactamente a la hora configurada (p. ej., 08:30 exacto).
|
||||
- Transición fin de día (23:59 → 00:00) en la TZ configurada.
|
||||
- Fija el comportamiento de ymdInTZ/hmInTZ.
|
||||
|
||||
### 6) ResponseQueue
|
||||
- [ ] Concurrencia de claimNextBatch:
|
||||
- Dos llamadas simultáneas no deben reclamar el mismo ítem.
|
||||
- [ ] markSent (si existe):
|
||||
- Marca “sent”, actualiza updated_at y deja de ser reclamable.
|
||||
|
||||
### 7) MaintenanceService
|
||||
- [ ] retentionDays = 0 o < 0:
|
||||
- No debe borrar nada.
|
||||
- [ ] Sin inactivos:
|
||||
- cleanupInactiveMembersOnce devuelve 0 y no toca filas activas.
|
||||
|
||||
### 8) Metrics
|
||||
- [ ] enabled():
|
||||
- Cubrir combinaciones: true/1/yes, false/0/no, undefined en test/prod.
|
||||
- Evitar emisión accidental en entornos no deseados.
|
||||
|
||||
### 9) DB/Pragmas y utilidades
|
||||
- [ ] getDb:
|
||||
- Crea directorio data (manejar EEXIST) y aplica PRAGMAs por defecto.
|
||||
- [ ] tableHasColumn (migraciones condicionales):
|
||||
- Comportamiento correcto con tablas parciales.
|
||||
|
||||
### 10) Salud y endpoints
|
||||
- [ ] /health sin ?full=1:
|
||||
- Respuesta básica “ok” sin suponer tablas opcionales.
|
||||
|
||||
## Priorización sugerida
|
||||
|
||||
1. Asignaciones por menciones (grupo) e integración desde WebhookServer.
|
||||
2. Concurrencia de claimNextBatch en ResponseQueue.
|
||||
3. Integridad referencial: cascada en task_assignments y FK de createTask con group inexistente.
|
||||
4. Robustez WebhookServer: JSON inválido y /metrics disabled.
|
||||
5. GroupSync: errores en fetchGroupMembersFromAPI y contenidos inesperados en syncGroups.
|
||||
6. Reminders: bordes de horario exacto y retención desactivada.
|
||||
7. “Tomar/soltar” con múltiples responsables.
|
||||
|
||||
## Notas de implementación
|
||||
|
||||
- Preferir tests end-to-end donde aporten valor (WebhookServer → CommandService → ResponseQueue/DB).
|
||||
- Aislar concurrencia con transacciones/estados consistentes; si procede, usar transacciones en claimNextBatch.
|
||||
- Mantener NODE_ENV y banderas (METRICS_ENABLED, TZ) explícitas por test.
|
||||
- Reutilizar DB en memoria con initializeDatabase y limpiar tablas entre casos.
|
||||
- Usar factories/helpers (p. ej., ensureUserExists) para preparar datos evitando duplicación.
|
||||
Loading…
Reference in New Issue