Automatisation UI pour les sites et applications que vous construisez vous-même

Ce que l'agent peut faire pour vos tests

• Fichiers read_file, write_file, append_file, edit_file, delete_file, make_dir, move_file, copy_file, list_dir, grep et glob fonctionnent dans le dossier de travail du chat, et un compteur affiche les fichiers créés, modifiés et lus.
• Shell exécute votre commande de test, un linter ou une compilation en local sur Windows, WSL ou via SSH sur un serveur que vous possédez, et juge le succès par le code de sortie réel. Les commandes dangereuses sont bloquées.
• Web web_search trouve des pages et http_get lit une page de documentation officielle, afin qu'une question sur un sélecteur ou une attente puisse être vérifiée contre le manuel du framework.
• Captures d'écran et images ocr lit le texte dans une capture d'écran sauvegardée, par exemple la bannière d'erreur d'un échec, et gen_image sauvegarde de vrais fichiers image lorsque vous en avez besoin.
• Orchestration task répartit les vérifications indépendantes entre des sous-agents en parallèle, run_on_model envoie une étape difficile à un modèle plus grand, et skill stocke un jeu de règles réutilisable comme votre routine de réparation habituelle.
• Modes d'approbation Auto-run agit immédiatement, Ask first fait une pause avant les actions qui modifient quelque chose et affiche le diff, et Plan only écrit un plan et ne lance rien. Les plans survivent aux redémarrages.
• Cron exécute une invite à intervalles réguliers, par exemple pour lancer votre commande de test aux heures que vous définissez et rapporter le code de sortie dans le chat, afin qu'un flux qui a échoué pendant la nuit soit la première chose que vous lisez.
• Modèles connectez un fournisseur d'IA cloud via un point de terminaison API standard, un modèle s'exécutant localement sur votre PC, ou le modèle intégré prêt à l'emploi sans votre propre point de terminaison. Le bouton Test vérifie un point de terminaison avant que vous ne commenciez.

Quatre tâches que l'agent effectue dans un projet de test

Écrire le premier flux

Les bonnes pratiques pour les tests e2e commencent par une courte liste de flux qui ne doivent jamais échouer, alors demandez à FlowLatch de n'écrire que ceux-là. list_dir et glob montrent comment vos tests existants sont nommés, read_file en ouvre un comme modèle, et write_file crée le nouveau fichier pour le flux de connexion avec un compte de test et des données factices. Shell lance ensuite votre commande de test, et la carte affiche le code de sortie réel. Une première ébauche est rarement définitive, alors demandez une modification à la fois, comme un nom plus clair ou une vérification ajoutée sur le texte de la page. Avant d'accepter, lisez le nouveau fichier dans le diff, exécutez-le vous-même une fois et ne le gardez que s'il correspond au flux que vous aviez en tête.

Exécuter la suite et lire l'échec

Shell lance votre commande de test et la carte conserve la sortie complète, donc un résultat rouge n'est jamais une supposition. grep recherche cette sortie pour l'étape qui échoue, et si votre framework a sauvegardé une capture d'écran, ocr lit le message qu'elle contient. Pour réduire l'instabilité dans les tests end to end, demandez à FlowLatch de relancer le test qui échoue avec la même commande et de comparer les codes de sortie. Un passage suivi d'un échec pointe vers une attente fixe, des données de test partagées ou l'ordre des tests. Demandez une explication courte dans le chat, puis passez-la en revue par rapport à la sortie avant de modifier un fichier.

Réparer un sélecteur après un changement de mise en page

Que les tests e2e valent le temps investi pour le travail frontend dépend du flux, alors couvrez d'abord la connexion et le paiement. Lorsque la mise en page de la page change, grep trouve tous les sélecteurs qui y étaient liés, read_file montre les étapes environnantes et edit_file propose des étiquettes stables ou des test ids à la place. Dans Ask first, FlowLatch fait une pause avant chaque modification et affiche un diff, un fichier à la fois. Acceptez les lignes qui semblent correctes, rejetez le reste, puis laissez Shell relancer la suite pour voir le nouveau code de sortie. Gardez le diff petit pour qu'un réviseur puisse le lire en une minute.

Déplacer une suite vers un autre framework

Lors de la migration de tests e2e entre des frameworks, conservez les deux suites dans le dépôt jusqu'à ce que la nouvelle passe. FlowLatch liste les anciens tests avec glob, lit chacun avec read_file et écrit le nouveau fichier correspondant avec write_file, un flux à la fois. web_search et http_get peuvent lire la documentation propre du nouveau framework pour la syntaxe dont vous ne vous souvenez plus. Lancez les deux suites avec Shell, comparez les codes de sortie, et approuvez chaque fichier dans Ask first avant que l'ancien ne soit supprimé. Les plans survivent aux redémarrages, donc une longue migration peut continuer le lendemain.