Locator auto-réparant (self-healing)

Un locator auto-réparant (self-healing locator) est un locator de test d’interface adossé à un mécanisme de récupération. Lorsque le locator principal ne trouve pas d’élément, par exemple parce qu’un id a changé, l’outil cherche dans la page l’élément qui correspond le mieux à ce qu’il savait de l’original (balise, texte, attributs, position, voisins), l’utilise et enregistre généralement cette « réparation » pour que quelqu’un mette le test à jour. Le but est de réduire les échecs causés par des modifications de markup sans conséquence.

Comment cela fonctionne en pratique

La plupart des implémentations suivent le même schéma :

1. Lors des exécutions réussies, stocker une empreinte de chaque élément manipulé par le test.
2. Lorsqu’un locator échoue, noter les éléments candidats de la page par rapport à cette empreinte.
3. Si le meilleur candidat dépasse un seuil, l’utiliser et journaliser la substitution ; sinon, échouer normalement.

Ce type de réparation par similarité d’attributs est bien établi : des outils commerciaux le proposent, et Healenium est une option open source pour Selenium. La réparation fondée sur un LLM, où un modèle lit la page ou l’arbre d’accessibilité et propose un nouveau locator ou un test corrigé, est plus récente. Les agents de test de Playwright, introduits en 1.56, comprennent un « healer » qui suggère des correctifs pour les tests en échec ; considérez-les comme des assistants qui proposent des modifications à relire, pas comme un pilote automatique.

Le vrai risque : réparer un vrai bug

Une réparation suppose que le changement était cosmétique. Ce n’est pas toujours le cas :

• Le bouton « Valider » a été supprimé par erreur, et le healer clique à la place sur « Enregistrer le brouillon ».
• Un champ a été renommé de « E-mail » en « Nom d’utilisateur », un vrai changement d’exigence que le test aurait dû signaler.
• Deux lignes similaires existent et le healer choisit la mauvaise : le test passe alors sur les mauvaises données.

Dans chacun de ces cas, un test qui devrait échouer passe au vert. Les règles qui gardent la réparation honnête :

• Signalez chaque réparation, et faites échouer l’exécution (ou au minimum signalez-la) dans la quality gate de release.
• Transformez les réparations en modifications de code. Acceptez ou rejetez le locator suggéré en revue ; ne laissez pas l’outil continuer à l’utiliser en silence.
• Vérifiez des résultats, pas seulement des interactions, pour qu’un clic sur le mauvais élément échoue quand même à l’assertion suivante.

Corrigez d’abord les locators

Une grande partie de la fragilité que vise le self-healing vient de sélecteurs fragiles : longues chaînes XPath, noms de classes générés, chemins fondés sur des index. Des locators orientés utilisateur comme getByRole('button', { name: 'Submit' }) de Playwright ou des attributs data-testid stables suppriment l’essentiel de ce besoin, sans aucune devinette.