1. Définir le contrat du formulaire
Nommez chaque champ à utiliser, les exemples valides et invalides, l’action de soumission et l’état final constituant une réussite. Un contrat utile précise ce qui apparaît après soumission, pas seulement que le bouton devient désactivé.
Utilisez des valeurs synthétiques et un environnement isolé. Si le formulaire exige un compte réel, un identifiant personnel ou un enregistrement de production, il ne s’agit plus d’un simple contrôle sans conséquence et il faut redéfinir les autorisations.
- Chaque champ possède une valeur de test sans risque.
- Au moins un cas invalide est défini.
- Les états de réussite et d’échec sont visibles et nommés.
- L’environnement et le retour arrière sont explicites.
2. Choisir le rôle navigateur le plus limité
agent-browser est un choix pratique pour une courte interaction dans le navigateur. browser-use peut être portable si la page et l’état final sont clairement définis. Quand le parcours devient un contrôle de non-régression, playwright-workflows ou webapp-testing apporte une meilleure couche de preuve grâce à des étapes et assertions répétables.
Ne demandez pas à un skill navigateur de déduire une autorisation. Une navigation réussie n’autorise pas l’envoi d’un message, la création d’un enregistrement ou la divulgation d’un identifiant secret.
3. Vérifier explicitement l’état final
Contrôlez les valeurs des champs, erreurs en ligne, position du focus, états activés ou désactivés, message de confirmation et éventuel enregistrement de test. Ne conservez capture ou journal que s’ils aident un autre relecteur à vérifier l’affirmation ; ne recueillez pas plus de données que nécessaire.
Répétez une fois depuis un état de navigateur propre. Si le résultat change, notez la dépendance — cache, connexion, temporisation ou sélecteur instable — au lieu de la cacher derrière un résultat positif.
- Les valeurs attendues sont encore présentes lors de la soumission.
- L’entrée invalide est refusée pour la raison attendue.
- Le message ou l’enregistrement final est vérifié, pas supposé.
- Une seconde exécution propre aboutit au même résultat ou explique l’écart.
4. S’arrêter avant les effets réels
Un test devient conséquent lorsqu’il envoie un vrai message, publie du contenu, modifie un compte, facture de l’argent, supprime un enregistrement ou téléverse des données personnelles. Considérez ces transitions comme des points d’arrêt et demandez au propriétaire de prendre la main pour l’étape finale.
La promesse utile de cet article reste donc limitée : vérifier un contrat de formulaire dans un environnement approuvé. Cela ne certifie ni l’application entière, ni tous les navigateurs, ni la sécurité du processus métier sous-jacent.