Adopta TDD para implementar pruebas efectivas con agentes de IA

Testing en la era de los agentes — TDD + agents, qué tests escribir tú vs cuáles el agente, snapshot testing inteligente

Tiempo estimado de lectura: 5 min

Ideas clave:

Usa tests como especificación (Test-Driven Prompting) y pide al agente implementar hasta que el test pase.
Los humanos deben definir contratos y tests críticos; los agentes pueden generar unit tests, edge cases y boilerplate bajo supervisión.
Cambia snapshots textuales por evaluaciones semánticas (LLM-judge) para reducir fragilidad.
Implementa un pipeline two-speed con sandboxes efímeros y telemetría sobre prompts y evaluaciones.

Tabla de contenidos

Introducción

Testing en la era de los agentes — TDD + agents, qué tests escribir tú vs cuáles el agente, snapshot testing inteligente debe aparecer en tu playbook desde hoy. Si vas a dejar que un agente (Claude Code, Aider, Cursor u otros) escriba código en tu repo, tienes que reordenar qué pruebas son autoritativas, cuáles automatizas y cómo evitas cobertura falsa.

Aquí está la estrategia práctica y accionable: cómo usar TDD como especificación, qué pruebas deben ser humanas, cuáles delegar a la IA, y cómo evolucionar los snapshots desde diffs frágiles a evaluaciones semánticas.

Resumen rápido (lectores con prisa)

Test-Driven Prompting aplica TDD a agentes: escribe el test como especificación y pide al agente implementar hasta que pase. Usa humanos para contratos, integración crítica y regresiones reales; delega unit tests deterministas y generación de edge cases al agente. Reemplaza snapshots textuales por una evaluación semántica (LLM-judge) que decide si un cambio es cosmético o funcional.

Test-Driven Prompting: TDD + agents, qué tests escribir tú vs cuáles el agente

Test-Driven Prompting es TDD adaptado a agentes. Escribes el test primero —no como un ejercicio de documentación, sino como la especificación no ambigua— y pides al agente que implemente hasta que el test pase. El test se convierte en el prompt más estricto que existe.

Beneficios inmediatos:

El agente no improvisa requisitos; el test define el contrato.
Evitas cambios colaterales porque la suite actúa como guardrail.
La revisión humana se traslada de “¿funciona?” a “¿es esto sostenible y seguro?”.

Pero atención: si el agente escribe la implementación y el test, obtendrás tautologías. Por eso la división de responsabilidades es crítica.

División práctica: qué escribe el humano y qué el agente

Lo que debe escribir el humano (no delegues)

Tests de integración críticos: pagos, auth, sincronización entre servicios. Requieren contexto de negocio y pruebas contra fallos reales.
Flujos E2E y guiones de usuario (Playwright, Cypress): definen la experiencia que no puede ser inferida por el agente. Playwright / Cypress
Tests de regresión con historial real: errores de producción documentados como tests que no pueden ser reinterpretados.
Setup de entornos y fixtures confiables: seeds de DB, contratos de mock globales.

Lo que el agente puede generar (con supervisión)

Tests unitarios para funciones puras: transformaciones deterministas, utilidades, algoritmos puros.
Generación de edge cases y fuzzing estructurado: inputs nulos, límites, arrays extremos.
Boilerplate de mocks simples y factories (bajo reglas estrictas definidas por humanos).

Pauta de revisión

Cualquier test con mocking complejo (p. ej. jest.mock con comportamiento dinámico) debe pasar revisión manual antes de merge. Los LLMs tienden a “alucinar” APIs de mocking o a asumir comportamiento de librerías.

Snapshot testing inteligente: de fragilidad a semántica

Cómo funciona

Los snapshots textuales mueren rápidos en repos de ritmo alto. La alternativa es snapshot testing inteligente: comparar semánticamente en lugar de por texto.

Cómo funciona:

Generas snapshot tradicional (DOM/JSON).
Si cambia, un módulo de evaluación semántica (LLM-as-a-Judge) recibe: snapshot antiguo, snapshot nuevo y una rúbrica.
El modelo decide si el cambio es cosmético (aprobable) o funcional (falla y requiere revisión).

Aplicaciones

UI: detectar si un botón cambió de estilo (aprobable) vs desapareció el control de envío (fallo).
APIs: admitir la adición de campos no utilizados por clientes y bloquear cambios en campos requeridos.

Herramientas/ideas

Construir un servicio interno que use un modelo de evaluación (ej. GPT-4o / Claude avanzado) y registre justificaciones estructuradas para auditoría.

Pipeline recomendado y consideraciones operativas

1. Golden Dataset de tests

Golden Dataset de tests: 20–50 casos representativos versionados en Git. Sirve como baseline para evaluar cambios de spec.

2. Two-speed CI

Cada PR: ejecución determinista rápida (linters, unit tests generados por agente, AST checks).
Merge/main: evaluación semántica completa (LLM-judge, snapshots semánticos).

3. Sandbox seguro para deterministas

Sandbox seguro para deterministas: ejecuta tests en contenedores efímeros sin red ni credenciales. Usa Firecracker o gVisor para aislamiento si ejecutas código generado automáticamente.

4. Métricas y guardrails

Pass rate determinista por PR.
Delta semántico medio por cambio de spec.
Flakiness score (casos inestables entre ejecuciones).
Cost per eval (tokens, tiempo).

Integración de herramientas de observabilidad: Promptfoo para orquestación local de evals, LangSmith para tracing, Braintrust para gestión de datasets.

Checklist mínimo antes de confiar en un agente

Tests críticos escritos por humanos y en el repo.
Golden Dataset versionado y ejecutable en CI.
Sandbox efímero con timeouts y sin acceso a prod.
Reglas claras de qué puede commitear el agente automáticamente.
LLM-judge configurado para snapshots y revisiones semánticas.
Telemetría: registro de prompts, respuestas, tokens y justificación del juez.

Conclusión: el rol del Tech Lead

Testing en la era de los agentes no elimina la responsabilidad humana; la traslada a la definición de contratos, gobernanza y métricas. El Tech Lead debe decidir qué pruebas son la fuente de verdad, cómo se auditan las decisiones del agente y cuándo intervenir manualmente. Si tratas los tests como especificaciones inmutables y habilitas snapshots semánticos, los agentes dejan de ser generadores de ruido y pasan a ser máquinas de productividad que se pueden gobernar.

Dominicode Labs

Para equipos que exploran evaluaciones semánticas y pipelines con agentes, Dominicode Labs ofrece recursos y patrones reproducibles para integrar LLM-judges y sandboxes en CI. Considera esta referencia como una continuación práctica de las ideas descritas arriba.

FAQ

¿Qué es Test-Driven Prompting?
¿Qué pruebas nunca debo delegar a un agente?
¿Cómo funcionan los snapshots semánticos?
¿Qué debo incluir en un Golden Dataset?
¿Cómo aislar el código generado automáticamente?
¿Qué métricas seguir para confiar en un agente?

Respuesta: Test-Driven Prompting aplica la práctica de escribir tests como especificaciones antes de implementar. El test actúa como el prompt más estricto para el agente y define el contrato que debe cumplirse.

Respuesta: No delegues tests de integración críticos (pagos, auth), flujos E2E, tests de regresión con historial real y el setup de entornos/fixtures. Estos requieren contexto de negocio y control humano.

Respuesta: Los snapshots semánticos usan un módulo de evaluación (LLM-judge) que recibe el snapshot antiguo, el nuevo y una rúbrica, y decide si el cambio es cosmético o funcional, registrando justificación para auditoría.

Respuesta: Un Golden Dataset incluye 20–50 casos representativos, versionados en Git y ejecutables en CI. Sirve como baseline para validar cambios de especificación.

Respuesta: Ejecuta código en contenedores efímeros sin red ni credenciales, aplica timeouts y usa tecnologías como Firecracker o gVisor para aislamiento.

Respuesta: Sigue métricas como pass rate determinista por PR, delta semántico medio por cambio de spec, flakiness score y cost per eval (tokens, tiempo). Complementa con telemetría de prompts y decisiones del juez.