# 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 ```bash # 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