agents_and_robots/dev/issues/0029-core-tests.md

0029 — Tests para runtime.go y config loader

Objetivo

Añadir tests unitarios para las dos piezas criticas del sistema que actualmente tienen 0% de cobertura: agents/runtime.go y internal/config/. Cubrir al menos los flujos principales (command routing, tool-use loop, config parsing).

Contexto

• agents/runtime.go (1,182 lineas) — 0 test files, 0 coverage
• internal/config/ (schema.go + loader.go) — 0 test files, 0 coverage
• Los tests existentes cubren bien pkg/ (puro) y parcialmente tools/
• Los unicos tests de integracion son E2E con Playwright (lentos, requieren infra)
• La falta de tests hace que refactors futuros (como 0026) sean arriesgados

Arquitectura

agents/runtime_test.go      NEW → tests de handleEvent, runLLM, tool-use loop
agents/lifecycle_test.go    → ya existe con tests basicos
internal/config/loader_test.go  NEW → tests de parsing y validacion
internal/config/schema_test.go  NEW → tests de defaults y campos requeridos

Patron pure core / impure shell

• Los tests de agents/ usaran mocks/stubs para dependencias impuras (Matrix client, LLM)
• Los tests de internal/config/ son puros (parsing de YAML)

Tareas

Fase 1: Test infrastructure

• 1.1 Crear helpers de test: mock CompleteFunc que devuelve respuestas configurables
• 1.2 Crear mock Matrix client (o interfaz minima para send)
• 1.3 Crear fixture de MessageContext para tests

Fase 2: Tests de config

• 2.1 Test: parsear config YAML minimo (solo campos requeridos)
• 2.2 Test: parsear config completo con todas las secciones
• 2.3 Test: expansion de env vars funciona ($VAR y ${VAR})
• 2.4 Test: config con campos desconocidos no falla (forward compat)
• 2.5 Test: valores default se aplican correctamente

Fase 3: Tests de command routing

• 3.1 Test: mensaje con !help resuelve a built-in command
• 3.2 Test: mensaje con !unknown devuelve error
• 3.3 Test: comando registrado con RegisterCommand se ejecuta
• 3.4 Test: comando custom no sobrescribe built-in

Fase 4: Tests de rule evaluation + LLM dispatch

• 4.1 Test: DM sin reglas → fallback a LLM
• 4.2 Test: DM sin LLM configurado → ignora mensaje
• 4.3 Test: regla matchea → ejecuta accion correspondiente
• 4.4 Test: ActionKindReply genera respuesta estatica
• 4.5 Test: ActionKindLLM invoca CompleteFunc con mensajes correctos

Fase 5: Tests de tool-use loop

• 5.1 Test: LLM responde sin tool calls → devuelve texto
• 5.2 Test: LLM pide tool call → ejecuta tool → devuelve resultado al LLM → respuesta final
• 5.3 Test: tool call falla → error se pasa al LLM como tool result
• 5.4 Test: max iterations se respeta (no loop infinito)
• 5.5 Test: RBAC deniega tool call → error al LLM

Fase 6: Cleanup

• 6.1 Verificar cobertura con go test -cover -tags goolm ./agents/... ./internal/config/...
• 6.2 Objetivo minimo: 50% coverage en ambos paquetes

---

Ejemplo de uso

# Correr solo los tests nuevos
go test -tags goolm -v ./agents/ -run TestHandleEvent
go test -tags goolm -v ./internal/config/ -run TestLoadConfig

# Cobertura
go test -tags goolm -cover ./agents/... ./internal/config/...

Decisiones de diseno

• Mocks simples, no frameworks: usar funciones Go nativas, no testify/mockery. Mantener dependencias minimas
• Tests de tabla (table-driven): para command routing y rule evaluation, usar sub-tests con nombre descriptivo
• No testear Matrix I/O: los tests de runtime usan stubs de send, no conectan a un homeserver

Prerequisitos

• Idealmente despues de 0026 (split runtime.go), pero puede hacerse antes si se estructura bien

Riesgos

• Acoplamiento a internals: tests de runtime.go dependeran de la estructura actual del Agent struct. Mitigacion: testear comportamiento (input → output), no estado interno
• Mocks divergen: si el API de shell/ cambia, los mocks quedan desactualizados. Mitigacion: interfaces minimas