Cypress tap abre la sesión en vivo del navegador al agente de código
La utilidad, en beta y para Cypress 15.21.0 o superior, expone el Command Log, el DOM y el árbol de accesibilidad de una sesión en modo open mediante comandos que devuelven JSON.
Cypress tap es una utilidad de terminal que se engancha a una sesión de Cypress en modo open para que un agente de código pueda mirar lo mismo que mira un desarrollador cuando depura a mano: el Command Log, el DOM en el comando que falló, el árbol de accesibilidad y el estado del navegador. Hasta ahora un agente podía lanzar cypress run, leer el código de salida y saber si el spec pasó, pero nada más. Ese hueco se nota cuando el fallo es visual o depende del estado.
La diferencia entre «no encontré el elemento» y saber por qué
Un element not found puede ser un selector mal escrito, una página que nunca cargó, un overlay tapando el control o una aserción mirando el intento de reintento equivocado. Son cuatro arreglos distintos y el mensaje de error no distingue entre ellos. Cypress tap añade subcomandos que devuelven JSON: specs, run, status, reporter, command, pin, aria e inspect. El bucle que propone el autor es ejecutar, esperar, inspeccionar y editar, en ese orden.
El detalle que rompe automatizaciones descuidadas está en run: lanza la petición y vuelve enseguida. No significa que el spec haya empezado ni terminado. El agente tiene que sondear status con su propio timeout hasta ver passed o failed. Y hay una trampa de estado obsoleto: el veredicto de la ejecución anterior sigue siendo legible hasta que arranca la siguiente, así que hay que comparar el campo startedAt con el momento en que se pidió la ejecución. Además cypress tap status sale con código 0 aunque el test haya fallado; la automatización debe ramificar sobre el JSON, no sobre el exit code.
Inspeccionar el intento que falló
Con el veredicto en la mano, reporter da rutas, hooks, Command Log y detalles del fallo. Si hubo reintentos, conviene mirar el intento fallido y no el último. A partir de ahí se acota: pin restaura el snapshot de un comando concreto dentro del frame de la aplicación bajo test, y dom, aria e inspect leen ese estado histórico. Es bastante mejor que pedirle a un modelo que adivine el navegador a partir de una cadena de error. El autor documenta también los reintentos de test, que son los que obligan a inspeccionar el intento y no la pantalla final.
El propio autor recomienda poner límites: un spec con nombre, un plazo de espera, inspeccionar solo el test que falla, permitir un único cambio de código, relanzar y parar pidiendo revisión humana si el segundo intento falla de otra forma. Un rerun en verde es necesario, pero no demuestra que el cambio haya conservado la aserción que se quería probar.
Beta y fronteras actuales
Cypress tap está en beta y necesita Cypress 15.21.0 o superior. Funciona con cypress open, no con cypress run en headless, y de momento exige un navegador basado en Chromium. Sus comandos y su salida pueden cambiar entre versiones, así que conviene guardar junto a cada informe la versión de Cypress, el navegador, el tipo de test, el identificador de sesión, la ruta del spec, el intento y el startedAt; si un campo cambia, el adaptador debería fallar en claro en vez de interpretarlo como un resultado nuevo. La documentación de cypress tap recoge el estado actual.
Y ojo con lo que se expone: el DOM, las rutas y las propiedades de consola salen por la terminal, y eso es material sensible cuando el agente manda contexto a un modelo remoto.
Lo interesante no es que la IA ejecute otro comando. Es que vea la misma evidencia que vería quien tiene que arreglarlo, y que el paso de «falló» a «sé por qué» deje de ser una inferencia.
