Vous avez une copie de staging de votre boutique, un compte de test et un dossier de tests, et vous voulez savoir si la connexion, l'ajout au panier et le paiement fonctionnent toujours après la mise à jour d'aujourd'hui. C'est le test web automatisé à son niveau le plus simple : un flux, une commande de test, un résultat lisible. FlowLatch ouvre le dossier, exécute la commande via Shell et affiche le code de sortie réel sur une carte. Si le flux échoue, il indique la ligne concernée et propose un correctif sous forme de diff, et vous décidez de l'accepter. Les étapes ci-dessous nécessitent 4 actions, du dossier au résultat. Travaillez uniquement sur une application que vous construisez ou que vous êtes autorisé à tester, utilisez le compte de test et des données fictives, et utilisez le mode test de votre propre configuration de paiement pour l'étape de paiement, jamais une vraie carte. Les vérifications par e-mail se font dans une boîte de test dédiée.
Démarrez FlowLatch, choisissez le dossier contenant vos tests comme dossier de travail, et sélectionnez Ask first pour que chaque action modifiant quelque chose attende votre validation. Connectez un modèle si ce n'est pas encore fait, et utilisez le bouton Test pour vérifier le point de terminaison.
Demande la structure des tests. list_dir et glob affichent les fichiers, et read_file ouvre le processus de validation pour que toi et l’agent partiez du même texte avant toute exécution ou modification. Chaque action apparaît dans le chat sous forme de carte avec son résultat.
Indiquez à l'agent quelle commande de test utilise votre projet. Shell l'exécute sur Windows ou dans WSL, et la carte affiche la sortie complète et le code de sortie réel, et non un résumé. Développez la carte si vous souhaitez voir chaque ligne, et utilisez grep dans la sortie pour passer directement à l'étape défaillante.
En cas d'échec, demandez ce que dit la sortie. L'agent propose une modification sous forme de diff, et rien n'est écrit jusqu'à votre acceptation. Rejetez ce qui semble incorrect, puis relancez la commande pour voir le nouveau code de sortie. Répétez jusqu'à ce que le flux réussisse ou que vous sachiez quoi modifier dans l'application.
tests/listétests/checkout-flow-test.txtchargéyour test commandexit 0FAIL reports/0 correspondances# 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 textCe squelette est en texte brut et se trouve dans le dépôt à côté de vos tests. Votre propre framework de test transforme chaque étape en code, et FlowLatch utilise le fichier comme spécification lorsqu'il écrit ce code, l'exécute et compare le résultat aux trois lignes d'attente. Modifiez le nom du produit et les pages pour correspondre à votre application de staging.
Commencez par demander où se trouvent les tests. list_dir affiche les dossiers, glob liste tous les fichiers correspondant à un motif comme les tests de commande, et read_file ouvre ceux qui vous intéressent pour voir comment un flux est construit aujourd'hui. grep recherche ensuite les sélecteurs et les attentes qu'ils utilisent. Tout cela ne fait que lire, c'est donc une première étape logique en mode Plan only, qui élabore un plan et n'exécute rien. Le plan survit à un redémarrage, vous pouvez donc y revenir demain. Lorsque vous êtes prêt pour des exécutions réelles, passez en mode Ask first et relisez le plan une fois de plus. Notez les flux déjà couverts, afin de savoir lesquels n'ont pas encore de test.
Après une mise à jour du runtime, les échecs de la suite e2e proviennent souvent de l'environnement plutôt que de votre application, alors lisez la première erreur avant de toucher à un test. Shell exécute votre commande de test et la carte conserve la sortie complète et le code de sortie réel, qui est le seul indicateur honnête de réussite ou d'échec. grep peut extraire l'étape défaillante d'un long journal. Demandez une explication claire de l'erreur dans le chat, comparez-la avec la sortie, et seulement ensuite décidez si un fichier de test nécessite une modification. Si l'erreur signale un package manquant ou un paramètre modifié, corrigez d'abord l'environnement et relancez la même commande. Souvent, la suite réussit alors sans aucune modification, et le code de sortie sur la carte le prouve.
La maintenance des sélecteurs dans l'automatisation des tests d'interface utilisateur est la tâche la plus courante, car une modification de la mise en page casse les sélecteurs qui y étaient liés. grep trouve l'ancien sélecteur dans tous les fichiers, read_file montre les étapes qui l'entourent et edit_file propose une étiquette stable ou un test id à la place. En mode Ask first, l'agent fait une pause et affiche le diff. Acceptez les lignes qui semblent correctes, puis laissez Shell exécuter la commande à nouveau. Un code de sortie vert après la modification est le résultat souhaité, et le diff reste dans l'historique de votre dépôt pour le prochain réviseur. Si la commande échoue toujours, lisez la nouvelle sortie avant de demander une autre modification, car une deuxième modification au-dessus d'une mauvaise hypothèse rend la cause plus difficile à identifier. Gardez chaque diff assez petit pour être lu en une seule séance.
Lorsqu'un test e2e d'interface utilisateur échoue, la cause réelle est souvent une attente fixe, des données de test partagées ou l'ordre des tests, et non l'application. Demandez à FlowLatch d'exécuter le test défaillant plusieurs fois avec la même commande et de rapporter chaque code de sortie. Des résultats mixtes signifient que le test est instable. Si votre framework a enregistré une capture d'écran, ocr lit le texte qu'elle contient, et le texte de la page lors de l'exécution échouée ajoute un deuxième indice. Corrigez l'attente ou les données dans un diff, révisez-le, et relancez le test. Fournissez à chaque test ses propres données et réinitialisez-les, attendez une condition visible au lieu d'une pause fixe, et gardez les tests indépendants de l'ordre des autres. Répétez l'exécution une fois de plus après la correction ; un seul passage prouve peu.
