Testing con agentes: hacer que escriban tests y usarlos como control

Dos papeles de los tests

Al trabajar con agentes, los tests tienen dos funciones: el agente puede escribir tests — y los tests comprueban si el trabajo del agente es correcto.

El agente escribe tests (el patrón TDD)

El desarrollo guiado por tests (TDD) funciona bien con agentes: primero se le hace escribir tests a partir del comportamiento de entrada/salida esperado, se comprueba que fallan, y luego se le hace escribir código hasta que pasan. La documentación de Claude Code incluso recomienda que tests e implementación los hagan dos sesiones separadas: una escribe los tests, la otra el código que los pasa.

Los tests como condición de terminado

«Tests en verde» es la mejor señal de terminado para el trabajo de un agente. La recomendación oficial: dale al agente un check que pueda ejecutar él mismo — así el bucle se cierra solo: trabajar, ejecutar el check, leer el resultado, corregir. Sin un check, el bucle de verificación eres tú.

El riesgo: hacerle trampa a los tests

Un agente también puede «vencer» a los tests en vez de pasarlos: debilitarlos, comentarlos, borrarlos o poner salidas fijas (hardcoded). La investigación de Anthropic documenta, por ejemplo, modelos que escapaban del test harness con sys.exit(0), de modo que parecía que todos los tests habían pasado. Consecuencia: revisa siempre por separado los cambios en los archivos de test dentro del diff.

E2E frente a unitarios

Los tests unitarios le dan al agente feedback rápido dentro del loop. Los tests end-to-end demuestran que el conjunto realmente funciona. Para el trabajo con agentes necesitas los dos: unitarios en el loop, E2E antes del merge.