Dos disciplinas, no una en sustitución de la otra
Diseñamos sistemas con IA aplicando dos disciplinas de testing complementarias: tests deterministas para la lógica del dominio y evals continuos para el comportamiento del modelo. Cada uno cubre un tipo de error distinto; entender la frontera entre ambos decide si el sistema entra en producción con confianza o con esperanza.
La tentación más frecuente en equipos que vienen de TDD clásico es asumir que sus tests bastan, o asumir que los evals los reemplazan. Las dos lecturas son incorrectas. Aquí va cómo se reparten el trabajo y cómo se integran en un pipeline serio.
Lo que TDD sigue cubriendo perfectamente
Un sistema con IA mantiene una mayoría de lógica que es determinista y, por tanto, testeable con tests clásicos:
- Validación de entrada y salida. Antes y después de cada llamada al modelo hay código que valida schemas, rangos, formatos. Eso se testa con tests unitarios.
- Lógica del dominio del agente. Las reglas de negocio que el agente aplica — umbrales de escalado, criterios de cualificación, políticas de pricing — viven en clases puras del dominio. Con stubs del puerto del LLM, esa lógica se testa de forma totalmente determinista.
- Integraciones con sistemas externos. Cada adapter (HubSpot, SAP, Postgres) tiene su test unitario con dobles y su test de integración contra un entorno controlado.
- Validación de tools. Cada tool MCP que el agente expone tiene contrato definido — parámetros, rangos, respuestas. Eso se testa antes de ejecutar nada con IA.
- Manejo de errores y fallbacks. Qué hace el sistema cuando el LLM falla, cuando una tool da timeout, cuando un dato externo viene corrupto. Lógica clásica, testing clásico.
En sistemas que entregamos, la cobertura de tests deterministas sigue siendo del orden del 70-80% de las líneas. La IA añade una capa nueva, no reduce la que ya existía.
Lo que TDD no cubre y nunca cubrirá
Hay tres tipos de error que los tests deterministas no detectan porque, por diseño, no pueden:
Decisiones del modelo en casos límite. El agente recibe una petición ambigua y decide; el modelo razonó de forma defendible, pero la decisión es subóptima para tu negocio. Ningún test unitario lo detecta porque el código se ha ejecutado correctamente.
Degradación silenciosa por cambios externos. El proveedor del LLM actualiza el modelo. Las respuestas cambian sutilmente: el agente empieza a citar menos las fuentes, o a escalar más al humano de lo necesario. Los tests siguen pasando; la calidad cae.
Comportamiento sobre datos reales que no estaban en tu dataset. El agente funciona bien con los 50 casos del PoC y empieza a fallar en escenarios reales que nadie había anticipado.
Los tres se atacan con evals: un conjunto de casos representativos, una rúbrica de juicio (humana, programática o LLM-as-judge calibrado), una métrica que se mide periódicamente. La salida no es PASS/FAIL — es una puntuación que se compara con la línea base histórica.
La pirámide de testing actualizada
La pirámide clásica (tests unitarios abajo, integración en medio, e2e arriba) sigue viva. Pero en sistemas con IA gana una capa más:
╱ Evals continuos
╱ (comportamiento del modelo,
╱ LLM-as-judge, drift)
╱─────────────────────────
╱ Tests E2E
╱ (flujos críticos de negocio)
╱──────────────────────────
╱ Tests de integración
╱ (adapters contra sistemas reales)
╱─────────────────────────────────
╱ Tests unitarios
╱ (dominio puro, validadores, tools)
Los evals se sitúan encima de la pirámide porque cubren menos casos pero detectan los problemas que ninguna capa inferior puede ver. No reemplazan ninguna capa; complementan.
Los evals tienen sus propias subdivisiones:
- Evals de retrieval sobre RAG:
recall@k,MRR, groundedness. - Evals de acción del agente: tool success rate, decision precision.
- Evals de respuesta: factual accuracy, tone, format, citation correctness.
Cada uno con su dataset, su rúbrica, su umbral de aceptación.
Cómo conviven los dos enfoques en CI
El pipeline que aplicamos en proyectos serios tiene tres niveles de validación:
Nivel 1 — en cada commit. Tests unitarios + lint + type-check. Suite que corre en menos de tres minutos. Bloquea el commit si falla. Cubre el 90% de los errores antes de que lleguen a producción.
Nivel 2 — en cada pull request. Tests de integración + tests E2E sobre flujos críticos. Suite que corre en diez a quince minutos. Adicionalmente, eval ligera sobre un dataset reducido (20-50 casos) si el PR toca prompts, retrieval o lógica del agente.
Nivel 3 — diariamente o tras release. Eval completa sobre el dataset extenso (200-500 casos). Compara con la línea base histórica. Genera alerta si una métrica baja más del umbral.
Esta estratificación equilibra velocidad y cobertura. Un cambio en un endpoint REST no necesita activar la eval completa; un cambio en el system prompt sí. La regla la define qué capa del sistema toca el cambio.
Anti-patrones que destruyen confianza en el sistema
Cuatro errores que vemos con frecuencia en equipos que adoptan IA y que invalidan la disciplina:
Tratar los evals como tests. El eval no es PASS/FAIL — es una métrica con tendencia. Un caso individual del eval puede fallar y no romper el build; lo que rompe el build es una caída agregada de la métrica.
Pretender que TDD cubre el modelo. Equipos clásicos a veces asumen que si los tests pasan, el agente funciona. Eso es cierto para la mitad determinista; falso para la mitad del comportamiento del modelo. Necesitas las dos disciplinas, no una.
Datasets de eval con casos sintéticos solamente. Casos generados con un LLM para testar otro LLM tienden a converger a lo que el modelo hace bien. El dataset útil contiene casos reales de producción — incluyendo los que fallaron en el primer mes de uso.
Sin LLM-as-judge calibrado. Usar LLM-as-judge sin haber comparado sus puntuaciones contra revisión humana en 50-100 casos produce una métrica que parece objetiva pero no lo es. La calibración no es opcional.
Un caso real: equipo TDD-clásico adoptando evals
Un cliente nuestro con equipo Symfony / Spring Boot consolidado y disciplina TDD madura incorporó un primer agente IA hace doce meses. El reto no era técnico — el equipo sabía testar — sino conceptual: la diferencia entre lo que cubre cada disciplina.
Lo que montamos durante el primer mes:
- Dominio del agente con cobertura clásica del 85% sobre las clases puras. Stubs del puerto del LLM, tests deterministas, ciclo rápido.
- Dataset inicial de evals con 80 casos curados a partir del PoC y de los primeros casos reales. Cada caso con entrada, salida esperada y rúbrica explícita.
- Pipeline CI con tres niveles (commit / PR / diario), ejecutando evals ligeras automáticamente cuando el PR tocaba prompts.
- Dashboard de métricas mostrando línea base y desviación por commit. Alertas por Slack si una métrica caía más del 3% sobre la base.
Resultado a seis meses: dos migraciones de modelo realizadas sin sobresaltos (cada una un PR, cuatro días entre PR y promoción, sin regresiones críticas), dataset crecido a 240 casos con incidentes reales incorporados, equipo que ahora razona sobre el coste-beneficio de cada capa de testing en lugar de defender el TDD como antes o desconfiar de los evals como hace un año.
Cómo lo construimos en producción
Cuando entramos en un proyecto donde un equipo TDD-clásico va a incorporar IA, el primer entregable no es el agente. Es el mapa de testing: qué cubre cada capa de la pirámide en este caso de uso concreto, qué dataset de evals necesita el agente, cómo se integra todo en el CI existente sin romper el ritmo del equipo.
Sobre ese mapa, los tests deterministas se mantienen exactamente como estaban — el equipo sigue trabajando con TDD donde tiene sentido. Los evals se añaden como capa nueva en CI y como práctica nueva en el flujo de trabajo. El equipo conserva lo ganado y suma la disciplina que el sistema con IA necesita.
Detrás de cada uno de estos sistemas hay un equipo de desarrolladores que cree que la calidad en sistemas con IA no es sustituir TDD con evals — es combinarlas con criterio. Los tests deterministas protegen lo predecible; los evals protegen lo probabilístico. Las dos disciplinas, no una.
Si tu equipo viene de TDD clásico y está incorporando IA en alguna pieza del sistema, podemos auditar el setup actual de testing y entregarte el plan para añadir la capa de evals sin desmontar lo que ya funciona.
