Testez votre application dans le navigateur d'une seule commande

Tapez /test dans le chat du projet, et Mythex teste votre application comme le ferait une personne : il ouvre l'aperçu en direct dans un navigateur, visite des pages, clique sur des boutons et remplit des formulaires, puis indique dans le chat ce qui a fonctionné et ce qui ne fonctionne pas. Vous pouvez lui indiquer un parcours précis — « teste l'inscription et la page de tarifs » — ou le laisser suivre le chemin le plus évident dans l'application.

Ce que cela fait

Les tests d'application éprouvent votre aperçu en direct, et non seulement votre code. Mythex pilote un navigateur sur l'application en cours d'exécution, capture ce qu'il voit — y compris des captures d'écran lorsqu'elles sont utiles — et rédige dans le chat un résumé des résultats.

C'est un type de vérification différent de la lecture du code source. Le code peut sembler juste et échouer tout de même à l'usage : un bouton relié au mauvais gestionnaire, un formulaire qui s'envoie sans jamais afficher de confirmation, une page qui ne plante qu'après la connexion. Seule l'utilisation de l'application permet de les trouver, et les tests d'application le font pour vous.

Pourquoi c'est utile

Lorsque vous construisez avec un agent, l'aperçu est la façon dont vous jugez l'avancement. Vous cliquez, cela semble correct, vous passez à la suite. Mais parcourir chaque parcours après chaque modification devient fastidieux, et il est facile de vérifier la page que vous venez de changer tout en ratant celle qu'elle a discrètement cassée.

Les tests d'application transforment la question « est-ce que ça fonctionne encore ? » en un seul message. Vous décrivez le parcours qui compte, l'agent le suit, et vous obtenez un rapport exploitable. Comme il s'exécute dans le même chat, la correction n'est qu'à un message de distance.

Comment le lancer

Assurez-vous que l'Aperçu fonctionne et affiche votre application. Les tests d'application s'exécutent sur l'aperçu ; si celui-ci est vide ou démarre encore, attendez-le ou réglez ce problème d'abord.
Tapez /test dans le chat du projet. Vous pouvez aussi le demander en langage courant — « teste l'application dans le navigateur » fonctionne également.
Indiquez sur quoi vous concentrer, si vous le souhaitez. Par exemple : « teste l'inscription et la page de tarifs », ou « crée un compte, ajoute un article, passe à la caisse ».
Lisez le rapport. Mythex résume ce qu'il a essayé et ce qui s'est mal passé, avec des captures d'écran lorsqu'elles aident.
Corrigez ce qu'il a trouvé avec /fix ou un message de construction normal.
Relancez /test pour confirmer que la correction fonctionne et que rien d'autre ne s'est cassé.

Quand l'utiliser

Après une grande modification de l'interface. Une nouvelle mise en page ou une nouvelle navigation peut casser des parcours que vous n'avez pas touchés directement.
Avant de publier, pour attraper les bris évidents avant que les visiteurs ne les voient.
Lorsque l'aperçu semble correct mais qu'un parcours pourrait ne pas l'être. Les parcours en plusieurs étapes — s'inscrire, puis se connecter, puis faire quelque chose — sont ceux qui méritent le plus d'être vérifiés.

Obtenir de bons résultats

Plus la demande est claire, plus le rapport est utile.

Décrivez un parcours nominal. « Crée un compte, ajoute un article, passe à la caisse » donne à l'agent une séquence claire à suivre et un résultat clair à vérifier. « Teste tout » le laisse deviner ce qui compte.
Nommez les pages ou fonctionnalités que vous avez modifiées. Si vous venez de refaire la page de tarifs, dites-le.
Testez par petites boucles. Modifiez quelque chose, testez, corrigez, testez à nouveau. Il est plus facile de voir ce qui a cassé lorsqu'une seule chose a changé.
Combinez avec les points de contrôle. Si une modification a cassé plus qu'elle n'en a réparé, vous pouvez revenir au dernier bon tour au lieu de corriger par-dessus.

Limites

Il teste l'aperçu, pas votre site publié. Les tests d'application s'exécutent sur l'aperçu en direct, dans votre espace de travail privé. Ils ne vérifient pas la version que les visiteurs voient à votre adresse publiée. Publiez séparément lorsque vous êtes prêt.
L'aperçu doit être en marche. S'il ne l'est pas, il n'y a rien à tester.
Il suit les parcours que vous lui indiquez. Une demande ciblée donne une vérification ciblée ; ce n'est pas une suite de tests exhaustive.
Il signale ; c'est vous qui décidez. Les tests d'application vous disent ce qui est cassé. La correction est une étape distincte, avec /fix ou un message de construction.

Si vous voulez approfondir la recherche d'un problème une fois repéré, notre guide sur comment déboguer une application construite avec l'IA explique la démarche. Pour l'aperçu lui-même, consultez un espace de travail privé et un aperçu en direct pour chaque projet.

La documentation contient les détails : Tests d'application.