Tienes una copia de staging de tu tienda, una cuenta de prueba y una carpeta con pruebas, y quieres saber si el inicio de sesión, la adición al carrito y el pago siguen funcionando tras el cambio de hoy. Esto es pruebas web automatizadas en su forma más sencilla: un flujo, un comando de prueba, un resultado que puedes leer. FlowLatch abre la carpeta, ejecuta el comando a través de Shell y muestra el código de salida real en una tarjeta. Si el flujo falla, señala la línea y propone una corrección como un diff, y tú decides si aceptarla. Los pasos a continuación requieren 4 acciones, desde la carpeta hasta el resultado. Trabaja solo en una aplicación que construyas o estés autorizado para probar, usa la cuenta de prueba y datos falsos, y usa el modo de prueba de tu propia configuración de pago para el paso de pago, nunca una tarjeta real. Las verificaciones por correo van a una bandeja de entrada de prueba configurada para ello.
Inicia FlowLatch, elige la carpeta que contiene tus pruebas como carpeta de trabajo y selecciona Ask first para que cada acción que modifique algo espere tu aprobación. Conecta un modelo si aún no lo has hecho, y usa el botón Probar para verificar el endpoint.
Pide la estructura de las pruebas. list_dir y glob muestran los archivos, y read_file abre el flujo de pago para que tú y el agente empiecen desde el mismo texto antes de que se ejecute o modifique algo. Cada acción aparece en el chat como una tarjeta con su resultado.
Indica al agente qué comando de prueba usa tu proyecto. Shell lo ejecuta en Windows o en WSL, y la tarjeta muestra la salida completa y el código de salida real, no un resumen. Expande la tarjeta si quieres ver cada línea, y usa grep en la salida para ir directamente al paso que falla.
En caso de fallo, pregunta qué indica la salida. El agente propone una edición como un diff, y nada se escribe hasta que lo aceptes. Rechaza lo que parezca incorrecto, luego ejecuta el comando nuevamente para ver el nuevo código de salida. Repite hasta que el flujo pase o sepas qué cambiar en la aplicación.
tests/listadotests/checkout-flow-test.txtcargadoyour test commandexit 0FAIL reports/0 coincidencias# checkout flow for the staging copy of my shop
# uses only the test account and fake data
step 1: open the sign-in page
step 2: sign in with the test account
step 3: search for the sample product
step 4: add the sample product to the cart
step 5: open the cart and start checkout
step 6: pay in the test mode of my payment set-up
expect 1: the order confirmation page is shown
expect 2: the order list shows the new test order
expect 3: the test inbox received the confirmation
# when a step fails, save a screenshot and the page textEste esquema es texto plano y se encuentra en el repositorio junto a tus pruebas. Tu propio framework de pruebas convierte cada paso en código, y FlowLatch usa el archivo como especificación al escribir ese código, ejecutarlo y comparar el resultado con las tres líneas expect. Cambia el nombre del producto y las páginas para que coincidan con tu propia app de staging.
Comienza preguntando dónde están las pruebas. list_dir muestra las carpetas, glob lista todos los archivos que coinciden con un patrón como las pruebas de pago, y read_file abre los que te interesan para que veas cómo se construye un flujo hoy. grep luego busca los selectores y las esperas que usan. Todo esto solo lee, por lo que es un primer paso sensato en Plan only mode, que escribe un plan y no ejecuta nada. El plan sobrevive a un reinicio, así que puedes volver a él mañana. Cuando estés listo para ejecuciones reales, cambia a Ask first y lee el plan una vez más. Anota los flujos que ya están cubiertos, para que sepas cuáles les falta una prueba.
Tras una actualización del entorno de ejecución, los fallos de la suite e2e a menudo provienen del entorno en lugar de de tu aplicación, así que lee el primer error antes de tocar una prueba. Shell ejecuta tu comando de prueba y la tarjeta conserva la salida completa y el código de salida real, que es el único pase o fallo objetivo. grep puede extraer el paso que falla de un registro largo. Pide una explicación clara del error en el chat, compáralo con la salida y solo entonces decide si un archivo de prueba necesita una edición. Si el error menciona un paquete faltante o una configuración cambiada, corrige el entorno primero y ejecuta el mismo comando nuevamente. A menudo, la suite pasa entonces sin ninguna edición, y el código de salida en la tarjeta lo demuestra.
El mantenimiento de selectores en la automatización de pruebas de interfaz de usuario es la tarea más común, porque un cambio en el diseño rompe los selectores que estaban vinculados a él. grep encuentra el selector antiguo en todos los archivos, read_file muestra los pasos a su alrededor y edit_file propone una etiqueta estable o un id de prueba en su lugar. En Ask first, el agente se detiene y muestra el diff. Acepta las líneas que parezcan correctas, luego deja que Shell ejecute el comando nuevamente. Un código de salida verde tras la edición es el resultado que deseabas, y el diff permanece en el historial de tu repositorio para el próximo revisor. Si el comando sigue fallando, lee la nueva salida antes de pedir otro cambio, porque una segunda edición sobre una suposición incorrecta hace que la causa sea más difícil de identificar. Mantén cada diff lo suficientemente pequeño como para leerlo en una sola sesión.
Cuando una prueba e2e de interfaz de usuario falla, la causa real suele ser una espera fija, datos de prueba compartidos o el orden de las pruebas, no la aplicación. Pide a FlowLatch que ejecute la prueba fallida varias veces con el mismo comando y reporte cada código de salida. Resultados mixtos indican que la prueba es inestable. Si tu framework guardó una captura de pantalla, ocr lee el texto en ella, y el texto de la página de la ejecución fallida añade una segunda pista. Corrige la espera o los datos en un diff, revísalo y ejecuta la prueba nuevamente. Asigna a cada prueba sus propios datos y restáuralos, espera una condición visible en lugar de una pausa fija, y mantén las pruebas independientes del orden de las demás. Repite la ejecución una vez más después de la corrección; un pase demuestra poco.
