Comment garder un workflow navigateur utile quand la page change ?

Que doit identifier un sélecteur ?

Privilégiez le libellé unique d’un champ, un rôle et son nom accessible, ou un identifiant de test stable. « Créer un client » décrit le bouton attendu plus clairement que le troisième bouton du deuxième panneau. Un texte seul peut aussi être ambigu si plusieurs panneaux répètent les mêmes mots.

L’enregistreur de Ritoko vérifie qu’une cible correspond uniquement à l’élément sélectionné et signale les cibles fragiles fondées sur la position. Vérifiez-les avant d’enregistrer. Un sélecteur de repli doit retrouver le même contrôle avec une autre propriété stable, et non n’importe quel bouton encore présent.

"target": {
  "primary": { "by": "role", "role": "button", "name": "Create customer" },
  "fallbacks": [{ "by": "testid", "id": "create-customer" }]
}

Cet exemple convient uniquement si les deux sélecteurs identifient de façon unique le vrai bouton de soumission de votre application. Ne reprenez pas cet identifiant de test pour un autre site.

Pourquoi un sélecteur correspondant ne suffit-il pas ?

Un bouton peut conserver le même nom tout en changeant de comportement. Vérifiez l’enregistrement obtenu, pas seulement la réussite du clic. Utilisez expect avec l’e-mail, la référence ou une autre preuve métier de la ligne courante. Ciblez une iframe dans le bon cadre et laissez le temps à la confirmation d’apparaître.

Définissez un point de départ reproductible pour chaque élément, comme la navigation vers un formulaire de création. Considérez les contrôles à sauvegarde automatique ou à soumission automatique comme des écritures possibles. Le succès du remplissage d’un champ ne prouve pas qu’aucune action irréversible n’a eu lieu.

Que faire quand une cible ne correspond plus ?

1. Inspectez l’étape en pause, la capture de page et l’action métier prévue.
2. Vérifiez si la page a changé ou si la connexion, l’authentification multifacteur, une erreur ou un mauvais compte explique le problème.
3. Choisissez une nouvelle cible unique pour la même action avec step_repair. Pour remplacer la cible d’un commit, il faut aussi fournir confirmCommitTarget: true après avoir vérifié qu’il s’agit du même contrôle de soumission.
4. Reprenez le lot. Avant la soumission, le formulaire de l’élément repart depuis le début ; après une soumission, seule une réparation admissible de confirmation peut continuer sur le même document.

Les sélecteurs de repli automatiques doivent aussi correspondre à un seul élément. L’exécuteur direct signale leur utilisation ; un repli pour l’étape commit déclenche un avertissement sur le bouton d’envoi. Le mode hôte ne propose actuellement ni réparation de sélecteur ni rapport sur les replis. Voir l’exécution et la reprise.

Et si le sélecteur a échoué après la soumission ?

Ne recréez pas l’enregistrement pour réparer son écran de reçu. Une cible de vérification manquante peut mettre en pause une fois le premier élément soumis ; d’autres échecs après commit peuvent passer en revue. L’absence du texte attendu est également un échec de vérification : changer de sélecteur ne suffit pas nécessairement.

Appliquez la procédure de reprise d’une écriture incertaine si le résultat n’est pas prouvé. La réparation restaure une cible ; elle n’établit pas si l’écriture métier précédente a réussi. Testez le workflow réparé sur un petit lot avant de l’utiliser dans un grand traitement récurrent.