agent
fc644ecd6e
Reemplaza el scaffold del echobot por la plataforma completa de bots traida desde ~/DataProyects/Github/agents_and_robots tras la operacion Matrix-out: los bots ya no hablan por Matrix sino por el bus unibus (modelo todo-rooms + E2E via shell/transportunibus sobre github.com/enmanuel/unibus/pkg/client). - go.mod: replace de unibus -> ../unibus y de fn-registry -> ../../../.. (paths relativos reajustados a la nueva ubicacion dentro de fn_registry). - app.md: bump a 0.2.0, descripcion + arquitectura + comandos + gotchas reales. - modulo Go conservado como github.com/enmanuel/agents (sin reescribir imports). agents_and_robots queda archivado como museo de la era Matrix.
100 lines
4.0 KiB
Markdown
100 lines
4.0 KiB
Markdown
# 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
|