Testez votre application dans le navigateur avec 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 les pages, clique sur les boutons et remplit les formulaires, puis indique dans le chat ce qui a fonctionné et ce qui ne fonctionne pas. Vous pouvez le cibler sur un parcours précis — « teste l'inscription et la page des tarifs » — ou le laisser suivre le chemin le plus évident dans l'application.

Ce que cela fait

Les tests d'application exercent votre aperçu en direct, pas 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 quand elles sont utiles — et rédige un résumé des résultats dans le chat.

C'est un contrôle différent de la lecture du code source. Le code peut sembler correct et échouer à l'usage : un bouton relié au mauvais gestionnaire, un formulaire qui s'envoie sans jamais afficher de confirmation, une page qui ne casse qu'après connexion. Le seul moyen de les trouver est d'utiliser l'application, et les tests d'application le font pour vous.

Pourquoi c'est utile

Quand vous construisez avec un agent, l'aperçu est le moyen de juger 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 modifier tout en manquant celle qu'elle a discrètement cassée.

Les tests d'application transforment « est-ce que ça marche encore ? » en un seul message. Vous décrivez le parcours qui compte, l'agent le parcourt, et vous obtenez un rapport exploitable. Comme cela se passe dans le même chat, la correction n'est plus qu'un message plus loin.

Comment le lancer

Assurez-vous que l'aperçu est en cours et affiche votre application. Les tests fonctionnent sur l'aperçu : si celui-ci est vide ou en cours de démarrage, attendez-le ou réglez ce point d'abord.
Tapez /test dans le chat du projet. Vous pouvez aussi demander en langage courant — « teste l'application dans le navigateur » fonctionne aussi.
Précisez le point à vérifier, si vous le souhaitez. Par exemple : « teste l'inscription et la page des tarifs », ou « crée un compte, ajoute un article, passe la commande ».
Lisez le rapport. Mythex résume ce qu'il a essayé et ce qui a mal tourné, avec des captures d'écran quand elles aident.
Corrigez ce qui a été trouvé avec /fix ou un message de construction classique.
Relancez /test pour confirmer que la correction fonctionne et que rien d'autre n'a cassé.

Quand l'utiliser

Après une modification importante 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 détecter les casses évidentes avant vos visiteurs.
Quand l'aperçu semble correct mais qu'un parcours pourrait ne pas l'être. Les parcours en plusieurs étapes — inscription, puis connexion, puis une action — sont ceux qui valent le plus la vérification.

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 commande » 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 fonctions que vous avez modifiées. Si vous venez de retravailler la page des tarifs, dites-le.
Testez par petites boucles. Modifiez quelque chose, testez, corrigez, retestez. Il est plus facile de voir ce qui a cassé quand un seul élément a changé.
Combinez avec les points de contrôle. Si une modification a cassé davantage qu'elle n'en a réparé, vous pouvez revenir au dernier tour fonctionnel 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 de votre espace de travail privé. Ils ne vérifient pas la version que voient les visiteurs à votre URL publiée. Publiez séparément quand vous êtes prêt.
L'aperçu doit être en cours. S'il ne tourne 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é. Le correctif est une étape distincte, avec /fix ou un message de construction.

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

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