SuriScope

Le problème

Un test qui échoue en recette pose toujours la même question : est-ce le produit, le test, ou l’environnement ? Et quand le test est bon, il reste à vérifier ce qui part réellement vers l’analytics, parce qu’un plan de marquage se valide rarement à l’œil.

SuriScope est né de ce double constat : les outils de sélection existants donnent un sélecteur sans dire s’il tiendra, et les vérifications de dataLayer se font dans la console, à la main, à chaque recette.

Ce que j’ai décidé

Chrome Manifest V3, React et Zustand, et surtout aucun service distant : tout est calculé dans l’onglet. Un outil de recette qui envoie la page du client quelque part n’est pas un outil qu’on peut utiliser chez un client.

Le sélecteur est produit par 34 stratégies CSS internes, 13 stratégies XPath et trois bibliothèques, puis noté sur 100 : classification de la stratégie, position dans le DOM, dépendance au texte, aux classes générées, à l’ordre des frères. Le score n’est pas décoratif : il est expliqué dans le panneau, avec les alternatives classées.

Puis un test de stabilité : quinze changements DOM plausibles (renommage de classes, insertion d’un frère, wrapper ajouté) sont appliqués puis annulés, et on regarde combien font échouer le sélecteur. Un sélecteur qui survit à douze sur quinze est un sélecteur qu’on peut mettre en CI.

Ce qui a cassé

Le premier scoring était binaire : le sélecteur tenait ou ne tenait pas. Sur de vraies pages il mentait — un `data-testid` et un `div:nth-child(3) > span` obtenaient la même note si aucun des deux ne cassait pendant le test.

Le second scoring était trop généreux avec les frameworks. Détecter React, Vue ou Angular (21 frameworks reconnus) ne dit rien de la stabilité du sélecteur : ça dit seulement que la page est hydratée. Ces points sont devenus une information affichée, pas une bonification.

Le vrai apprentissage : un score doit pouvoir être contesté. Chaque point retiré est affiché avec sa raison, sinon l’outil devient une boîte noire qui donne raison à celui qui la lit.

Le reste de l’atelier

Autour du sélecteur : génération de code Playwright (locators lisibles `getByTestId`, `getByRole`), Cypress, Selenium Java et Python, Page Object ; vérification d’un script entier collé d’un coup ; bibliothèque de sélecteurs annotés et exportables ; outils d’élément (styles réels, contraste calculé, test d’un clic).

Et le gel de page : figer le DOM pour inspecter un menu qui ne s’affiche qu’au survol. C’est la fonctionnalité la plus banale et celle qui sert le plus souvent.