Cómo Verificar Código Generado por IA Antes de Fusionarlo

El problema de revisar código que no escribiste

Un agente de codificación de IA puede producir una funcionalidad que funciona en minutos. El cuello de botella se movió: la restricción ya no es qué tan rápido se escribe el código, sino con cuánta confianza alguien puede decir que el código hace lo que se suponía que debía hacer. Leer un diff grande con cuidado toma más tiempo del que tomó generarlo.

Las verificaciones de tipos y las pruebas unitarias confirman que el código hace lo que se escribió para hacer. No pueden decirte si la aplicación desplegada aún funciona, porque nunca abren una. Esa brecha es donde realmente viven las regresiones generadas por IA.

El ciclo, en tres comandos

Instala el CLI de código abierto de TestSprite — gratuito, Apache-2.0, Node 20.19+, 22.13+, o 24+:

npm install -g @testsprite/testsprite-cli
testsprite setup

Luego el ciclo. Describe el comportamiento que quieres garantizado, ejecútalo contra un navegador real, y lee el veredicto a partir del código de salida:

# 1 — create the test and run it
testsprite test create --project prj_abc123 --type frontend \
  --plan-from ./checkout-flow.plan.json --run --wait --output json
#   → exit 1: the run failed

# 2 — pull ONE self-consistent failure bundle
testsprite test failure get test_3a9f21c7 --out ./.testsprite/failure

# 3 — fix the code, then replay the same test
testsprite test rerun test_3a9f21c7 --wait --output json
#   → exit 0: passed

El paquete en el paso dos es la parte que importa. Contiene el paso que falló, sus pasos vecinos, capturas de pantalla, instantáneas del DOM, el código fuente de la prueba, una hipótesis de causa raíz, y un objetivo de corrección recomendado — todos compartiendo un único id de instantánea. El CLI se niega a combinar datos de dos ejecuciones diferentes, así que un agente nunca razona sobre un contexto ensamblado a partir de dos estados diferentes de la aplicación.

Por qué una suite duradera vence a una ventana de contexto más grande

Cada prueba que pasa queda guardada. La próxima vez que el agente toque la base de código, ese requisito se sigue verificando — esté o no en algún lugar de la conversación actual.

Este es el argumento estructural a favor de la verificación externa. Una ventana de contexto contiene en lo que el agente está pensando en este momento. Una suite de pruebas contiene cada requisito que el proyecto ha logrado cumplir correctamente, y sigue reteniéndolos a través de sesiones, a través de agentes, y a través de los meses en que nadie recuerda por qué importaba un caso límite en particular.

Configura tu agente para que haga esto por sí mismo

No deberías tener que transmitir comandos entre una página web y tu agente de codificación. Un solo comando de configuración instala un archivo de skill en el repositorio que describe el ciclo en la forma en que un agente realmente lo consume:

TESTSPRITE_API_KEY=sk-... testsprite setup --from-env --yes --agent claude

Los entornos compatibles son claude, codex, cursor, cline, antigravity, kiro, windsurf, y copilot. La instalación es puramente local. Después de eso, el agente sabe cómo crear, ejecutar, y triar pruebas sin que se le indique de nuevo en cada sesión.

Antes de gastar un turno en un comando que fallará por razones ambientales, verifica el entorno:

testsprite doctor    # CLI and Node versions, profile, credentials, connectivity

Qué verificar primero

No todo merece una prueba de extremo a extremo. En una base de código que cambia rápidamente bajo un agente de IA, la cobertura de mayor valor es estrecha:

1. Los flujos que producen ingresos. Registro, pago, y facturación. Una regresión aquí cuesta dinero de inmediato y con frecuencia es invisible en las pruebas unitarias.

2. Cualquier cosa que involucre autenticación. El manejo de sesiones, las redirecciones después del inicio de sesión, y los límites de permisos son donde una refactorización que parece plausible causa más daño.

3. Formularios y validación. Baratos de describir, desproporcionadamente propensos a romperse cuando se actualiza una biblioteca de componentes o se renombra un campo.

4. Los últimos tres errores que lanzaste. Una prueba de regresión escrita después de una corrección es la prueba de mayor rendimiento en cualquier suite.

Si prefieres que el primer conjunto te sea propuesto, la exploración puede redactarlas. Las propuestas quedan preparadas para revisión y nada se escribe en tu disco hasta que aceptes:

testsprite test plan generate --project prj_abc123
testsprite test plan accept --project prj_abc123           # all of them
testsprite test plan accept --project prj_abc123 --only prop_2 prop_5

Hacer que la verificación sea obligatoria

Un paso de verificación que solo se ejecuta cuando alguien recuerda ejecutarlo no es verificación. Ponlo en CI:

testsprite ci init github

Eso genera .github/workflows/testsprite.yml usando TestSprite/testsprite-action@v1, que anota la pestaña de verificaciones del PR con un error por cada fallo, agrega una tabla de resultados al resumen del job, sube un reporte JUnit, y — de forma importante — hace fallar el job en una ejecución parcial en lugar de reportarlo como exitoso.

Ese es el camino donde tu flujo de trabajo conduce la ejecución. TestSprite también se instala como una GitHub App que escucha los eventos de despliegue que tu pipeline ya produce y comenta los resultados de vuelta en el pull request, lo cual no necesita ningún archivo de flujo de trabajo ni ningún cambio en el repositorio.

En cualquier otro sistema de CI, el CLI solo necesita una clave de API en el entorno:

export TESTSPRITE_API_KEY="$TESTSPRITE_API_KEY"
testsprite test run --all --project prj_abc123 --wait \
  --report junit --report-file testsprite-junit.xml \
  --summary-file testsprite-summary.json

Códigos de salida sobre los que vale la pena ramificar

Los códigos 129, 130, y 143 significan que el proceso fue interrumpido por una señal (128 más el número de señal), no que una prueba falló — vale la pena distinguirlo antes de reportar una ejecución como rota.

Preguntas frecuentes