Tester des composants

Votre formulaire d'inscription est couvert par quatorze tests, tous verts. Le mois dernier, un développeur a remplacé <div class="erreur"> par un composant <Alerte> qui applique des classes utilitaires générées. Les quatorze tests, qui cherchaient .erreur avec querySelector, sont passés au rouge en bloc alors que le produit fonctionnait parfaitement. Deux heures plus tard, ils étaient réparés — puis, la semaine suivante, un vrai bug est passé : le message d'erreur s'affichait bien, mais sans lien avec le champ concerné, donc invisible pour un lecteur d'écran. Aucun test ne l'a vu.

Ces deux échecs ont la même cause. Interroger le DOM par classe CSS teste la structure interne du rendu, pas ce que l'utilisateur perçoit. La structure change constamment sans que le comportement bouge, ce qui produit des faux positifs ; et elle reste identique quand l'accessibilité se dégrade, ce qui produit des faux négatifs. La correction est mécanique : cherchez vos éléments par leur rôle accessible et leur nom accessible, exactement comme le fait un lecteur d'écran ou un utilisateur au clavier. Vos tests deviennent alors insensibles aux refontes de style et sensibles aux régressions qui comptent vraiment.