Cómo probar código generado por IA con pruebas end-to-end independientes

Qué significa probar código generado por IA

Probar código generado por IA significa demostrar que su aplicación sigue haciendo lo que sus usuarios necesitan después de que un agente de programación con IA la haya cambiado.Al usuario no le importa quién escribió las líneas.Lo que importa es si el inicio de sesión sigue funcionando, si el total sigue siendo correcto y si el botón sigue ahí.

Los agentes de programación ya hacen mucho más que completar una línea.Claude Code, Cursor, GitHub Copilot, OpenAI Codex y Devin pueden asumir una tarea, cambiar muchos archivos, ejecutar comandos y abrir una pull request.Algunos equipos van más allá y practican el vibe coding: describen lo que quieren, aceptan lo que reciben y rara vez leen el código.

El código llega ahora más rápido de lo que nadie puede revisarlo.Un revisor recibe un diff de cientos de líneas repartidas en una docena de archivos, y un diff nunca muestra la aplicación en funcionamiento.Probar en el desarrollo agéntico consiste en cerrar esa brecha: una comprobación de la aplicación terminada que no depende de leer el código.

Por qué no bastan las pruebas del propio agente

La primera idea es pedir al agente que escriba también las pruebas.Hágalo: las pruebas unitarias detectan errores reales, y un agente las escribe rápido.Pero una prueba escrita por el agente que escribió el código comparte su interpretación de la tarea.Si el agente entendió mal el requisito, el código y la prueba coinciden entre sí, y ambos están mal.

Las pruebas a nivel de código tienen más puntos ciegos que un requisito mal entendido.

Estos puntos ciegos tienen algo en común: son invisibles desde dentro del código.La demostración tiene que venir de fuera, de la aplicación en funcionamiento, vista como la ve un usuario.

¿Lo resuelven las pruebas end-to-end con autorreparación?

Las pruebas end-to-end son la respuesta clásica.Una prueba end-to-end maneja la aplicación real a través de su interfaz, como lo hace un usuario, y verifica lo que ocurre.La mayoría de los equipos las escribe como código, con Playwright, Cypress o Selenium: se escribe un selector para cada elemento y una línea de código para cada clic.

Los agentes escriben bien ese código, y las herramientas ahora los ayudan.Playwright incluye agentes de prueba: un planificador, un generador y un reparador que vuelve a ejecutar una prueba fallida, inspecciona la página y corrige la prueba hasta que se supera, o la marca como omitida cuando cree que la funcionalidad está rota.El cy.prompt de Cypress convierte pasos escritos en inglés sencillo en comandos de Cypress y repara un paso cuando su selector o su texto cambian entre ejecuciones.Playwright MCP permite a un agente manejar un navegador mediante las instantáneas de accesibilidad de la página.

La reparación es útil, porque la mayoría de las pruebas end-to-end rotas se deben a un selector renombrado, no a un error.El riesgo aparece cuando un mismo agente lo hace todo: escribe la funcionalidad, escribe la prueba y repara la prueba cuando falla.Cada reparación es razonable por sí sola.Juntas pueden desplazar la prueba de lo que el usuario necesita a lo que el código resulta que hace.

Para comparar las propias herramientas de pruebas end-to-end, consulte el estudio comparativo.

¿Cómo se prueba end-to-end el código generado por IA?

Seis hábitos convierten las pruebas end-to-end en una barrera de protección que un agente no puede esquivar con argumentos.Ninguno de ellos necesita una herramienta concreta.

1. 1

   Poner por escrito los recorridos que nunca deben romperse

   Enumere entre cinco y diez flujos de trabajo sin los que sus usuarios no pueden vivir: registrarse, iniciar sesión, buscar, añadir al carrito, pagar, exportar un informe.Escriba cada uno como se lo explicaría a un tester nuevo, con su resultado esperado.Esa lista es su especificación, y le pertenece a usted, no al agente.

2. 2

   Crear la prueba antes de que el agente escriba el código

   Cuando un recorrido es nuevo, cree primero su prueba end-to-end, a partir del diseño o de los pasos.Así el agente trabaja hacia un objetivo que no eligió él.La prueba falla hasta que la funcionalidad hace lo que debe: el desarrollo guiado por pruebas, aplicado a los agentes.

3. 3

   Comprobar lo que ve el usuario

   Verifique la pantalla: las palabras que lee un usuario, el aspecto de un elemento, la disposición de las cosas.Evite comprobaciones de ids internos, nombres de clase y estados que solo conoce el código, porque eso es exactamente lo que un agente cambia con total libertad.Una prueba anclada en la pantalla resiste una reescritura del código que hay debajo.

4. 4

   Mantener las pruebas fuera del alcance del agente

   Guarde las pruebas junto al código, pero haga que cada cambio en ellas requiera la revisión de una persona.En GitHub, una entrada CODEOWNERS para la carpeta de pruebas, con la aprobación de los propietarios del código exigida antes de una fusión, hace exactamente eso.El agente puede ejecutar las pruebas y proponer un cambio en una de ellas.Nunca fusiona ese cambio por su cuenta.

5. 5

   Ejecutarlas en cada pull request

   Ejecute las pruebas de regresión end-to-end en cada pull request que abra el agente, en una máquina que muestre la aplicación real, y haga que un fallo bloquee la fusión.Un resultado que solo avisa pronto se ignora.Lo que hace que las ejecuciones se superen siempre, desde un tamaño de pantalla fijo hasta un estado inicial conocido, está en Ejecutar una prueba.

6. 6

   Hacer que los fallos sean legibles para el agente y para usted

   Una prueba fallida debería decir qué falló, dónde y en qué se diferencia la pantalla de lo esperado, con imágenes.El agente lo usa para proponer una corrección.Usted lo usa para decidir si el cambio fue un error o algo intencionado.

Dónde sigue la persona en el bucle

Mantener a una persona en el bucle no significa que alguien lea cada línea de código.Significa que una persona es la responsable de las decisiones que el código no puede tomar por sí mismo.

Las herramientas de revisión de código con IA ayudan con la segunda fila: leen un diff y señalan el código arriesgado.Aun así miran el código, no la aplicación en funcionamiento.La ejecución end-to-end es la única comprobación que mira el producto.

Pruebas end-to-end para agentes de programación con IA, con GUI Test Studio

GUI Test Studio se construyó para este reparto de funciones.Una persona graba la prueba o la describe, el agente la ejecuta y lee el veredicto, el pipeline la ejecuta en cada build, y un cambio en lo que espera la prueba aguarda a una persona.

Una prueba que no depende del código

Grabe el flujo de trabajo una vez en GUI Test Runner-Recorder, haciendo clic y escribiendo en la aplicación real, o descríbalo en una petición a Claude, a ChatGPT o a un modelo de IA local en su propio equipo, uno nuestro o uno suyo.En ambos casos, la prueba comprueba la pantalla.Una aserción visual compara la imagen de un elemento, una aserción de texto lee sus palabras, una aserción de disposición verifica cómo están colocados los elementos.

No hay ningún selector que escribir ni código de prueba que el agente pueda reescribir.El GTS Engine + AI encuentra cada elemento mediante lo que la aplicación dice de él, su información de accesibilidad, y visualmente cuando no dice nada.Una clase renombrada o un componente reescrito no rompen la prueba.Cuando un asistente crea una prueba por usted, cada comprobación que añade se evalúa en el momento y se rechaza si no pudiera superarse en la pantalla ahora mismo.

El agente la ejecuta y lee el veredicto

GUI Test Studio incluye un conector MCP, así que el asistente que escribe su código también puede ejecutar sus pruebas.Funciona con Claude Code, Claude Desktop, ChatGPT con Codex y Copilot Chat en VS Code, conectados con un clic, y con cualquier otro asistente que acepte un conector MCP.

Run the Checkout test and tell me what failed.

Una ejecución fallida se explica a partir de su informe, nunca se responde volviendo a grabar la prueba, salvo que usted lo pida.A través del conector, la prueba que juzga el cambio del agente sigue siendo la que usted aprobó hasta que confirme un cambio en ella.

En cada pull request, con gtr-cli

gtr-cli ejecuta las mismas pruebas desde su pipeline, en una máquina de compilación Windows, y responde como espera un pipeline.Su código de salida hace fallar el build, un archivo JUnit rellena la pestaña de pruebas, un archivo JSON queda disponible para un script o un agente, y un resumen en Markdown está listo para la pull request.Una ejecución desde gtr-cli nunca modifica el archivo de prueba.

gtr-cli run tests --countdown 0 --format github --junit results\junit.xml ^
  --json results\run.json --summary results\summary.md --artifacts results\artifacts ^
  --jira on-failure

Con --jira on-failure, una prueba fallida se convierte en una incidencia de Jira con los pasos para reproducirla y las imágenes esperada y encontrada, y el mismo fallo visto de nuevo añade un comentario en lugar de un duplicado.El mismo comando funciona en GitHub Actions, GitLab, Azure DevOps, Jenkins y TeamCity: consulte Ejecutar pruebas en su pipeline, y Ejecute sus pruebas end-to-end en cada build para una configuración de TeamCity paso a paso.

Una segunda mirada, y la última palabra de una persona

Cada ejecución termina en un Informe de confianza que dice, para cada comprobación, si se encontró el elemento y si coincide con lo grabado.Cuando una comprobación falla por píxeles, el Análisis inteligente con IA puede echar una segunda mirada: ignora el ruido de renderizado inofensivo y aun así detecta las regresiones reales, como una palabra cambiada, una insignia que falta o un botón que se volvió gris.Cuando está activado, su respuesta es el veredicto final de esa comprobación, con lo que cambió en palabras sencillas.Se ejecuta en la nube con su propia clave de OpenAI o de Anthropic, o con un modelo de IA local en su propio equipo: uno nuestro, o uno suyo.

Ampliar

Cuando la aplicación cambió a propósito, una persona acepta el nuevo aspecto en el informe y lo guarda, y a partir de entonces la prueba lo espera.Cómo leer el informe está en Leer el Informe de confianza.

Esta guía es el lado práctico de las pruebas.Para el ciclo completo del desarrollo con agentes de IA, desde la petición hasta el bug de Jira que corrige el agente, lea Desarrollo con agentes de IA (ADLC).

Preguntas

Claude, Cursor, GitHub Copilot, OpenAI Codex, ChatGPT, Devin, Playwright, Cypress, Selenium, Jira y TeamCity son marcas comerciales de sus respectivos propietarios.