Quels sélecteurs utiliser pour vos tests web ?

Dès qu’on veut automatiser des tests, il faut localiser les éléments avec lesquels on veut interagir. Les 2 types de sélecteurs pour faire cela sont :

les sélecteurs CSS
le langage XPath

Ils parcourent tous deux le Document Object Model (DOM) (soit la représentation XML ou HTML d’une page, cf exemple ci-dessous), et en extraient les éléments demandés. Ils sont tous 2 utilisables avec n’importe quel langage de programmation.

CSS Selectors

Les sélecteurs CSS (Cascading Style Sheet) allient puissance, rapidité et concision. Ils sont donc un choix pertinent dans énormément de vos sélecteurs.

Voici la liste des sélecteurs CSS à connaitre par coeur :

X pour chercher les balises de type <x>
.classname pour chercher les éléments qui ont l’attribut class="classname"
On peut mixer les 2 points ci-dessus en un seul élément, comme h1.foo pour récupérer tous les noeuds h1 qui ont une classe “foo”)
#idname pour chercher les éléments qui ont l’attribut id="idname"
[attribute-name="foo"] pour chercher les éléments qui ont un attribut “attribute-name” avec la valeur “foo”
[attribute-name^="foo"] pour chercher les éléments qui ont un attribut “attribute-name” dont la valeur commence par “foo”
[attribute-name*="foo"] pour chercher les éléments qui ont un attribut “attribute-name” dont la valeur contient “foo”
[attribute-name$="foo"] pour chercher les éléments qui ont un attribut “attribute-name” dont la valeur se termine par”foo”
li a pour tous les descendants de li qui sont de type a
li > a pour tous les descendants directs de li qui sont de type a
ul li:first-child, :nth-child(N), et :last-child pour respectivement retourner le premier, le N-ième, et le dernier enfant (de type li dans notre exemple)

Il n’existe pas de sélecteur CSS se basant sur le texte affiché à l’écran, ce qui peut être bloquant dans certains cas. De même, il est impossible de remonter dans l’arborescence du DOM avec les CSS selectors.

Si vous voulez une liste plus complète de CSS sélecteurs, je vous invite à aller voir https://www.freecodecamp.org/news/css-selectors-cheat-sheet/.

Avant de choisir un sélecteur CSS, testez le toujours dans la console de votre navigateur, via la commande

$('...') pour ne retourner que le premier élément correspondant
$$('...') pour retourner l’ensemble des éléments correspondants.

Personnellement, je recommande de toujours utiliser le $$('...') pour être sûr que votre sélecteur ne correspond pas à plusieurs éléments.

XPath

Le langage XPath est beaucoup plus puissant que les CSS : on peut naviguer de manière beaucoup plus précise dans le DOM, mais cela se fait au prix d’une moins bonne lisibilité.

Si vous souhaitez une documentation complète sur les XPath, je vous invite à consulter la cheatsheet https://devhints.io/xpath. Pour autant, pour l’utilisation dans des tests automatisés, la liste suivante devrait répondre à l’immense majorité de vos besoins :

//div sélectionne toutes les balises div
//div[@attribute-name="foo"] sélectionne toutes les balises ayant un attribut "attribute-name='foo'"
//*[starts-with(@attribute-name,"foo")], //*[contains(@attribute-name,”foo”)], //*[ends-with(@attribute-name,”foo”)] sélectionnent respectivement toutes les balises ayant un attribut "attribute-name" commençant, contenant, et se terminant par “foo”
//div//li sélectionne tous les li descendants de div
//div/li sélectionne les li descendants directs de div
//div/li[1] pour div > li:first-child en CSS
//div/li[2] pour le div > li:nth-child(2) en CSS
//div/li[last()] pour le div > li:last-child
//button[text()="Submit"] sélectionne les éléments de type button et dont le texte affiché est “Submit”
//button[contains(text(), "Submit")] sélectionne les éléments de type button et dont le texte affiché contient “Submit”

A noter qu’il est aussi possible avec XPath de remonter dans l’arborescence grâce à /../.

De la même manière que pour les sélecteurs CSS, utilisez $x(‘…’) dans la console pour tester votre sélecteur XPath pour vous assurer qu’il ne correspond pas à plusieurs éléments.

Le bon et le mauvais sélecteur

Maintenant que nous connaissons l’essentiel de ces sélecteurs, cherchons ce qui différencie un bon d’un mauvais sélecteur.

Un bon sélecteur doit être :

court : si votre sélecteur a 4 étages ou plus (comme div > ul li a), vous vous y êtes sûrement mal pris. Il doit être possible de trouver un sélecteur plus direct, ou de retirer certains étages superflus.
unique : si votre sélecteur n’est pas suffisamment précis, il risque de cibler d’autres éléments : vous obtiendrez alors des comportements étranges dans vos tests (potentiellement pénibles à débugger).
robuste face aux évolutions logiciel : si votre sélecteur est trop dépendant de l’arborescence, il y a un fort risque que la moindre évolution graphique casse votre sélecteur.

Je conseille d’utiliser les CSS selectors dès que possible pour profiter pleinement de leur lisibilité. Pour autant, certaines situations sont plus adaptées aux XPath, donc ne les boycottez pas complètement : sachez passer de l’un à l’autre dès que nécessaire.

Créez vos propres attributs d’éléments

Tous ces sélecteurs sont très pratiques, mais malgré tous vos efforts, vos sélecteurs peuvent quand même casser lorsque la UI évolue. Et autant dire que, vu la vitesse de mises à jour dans une équipe agile, on peut être amené à changer nos sélecteurs très (trop !) régulièrement.

Autre point notable, certains attributs (comme la class) sont générés aléatoirement avec certaines librairies React. Impossible alors d’utiliser des sélecteurs se basant dessus puisqu’ils changent à chaque utilisation.

La meilleure solution consiste alors à créer vos propres attributs. Pour cela :

choisissez avec les développeurs un nom d’attribut qui sera dédié à l’automatisation des tests (chez Slack, ils ont choisi “data-qa” par exemple ; cf screenshot ci-après)
créez dans votre librairie de tests une fonction qui permet de cibler ce sélecteur simplement
pendant la spécification des features (pendant les 3 amigos par exemple), indiquez aux développeurs quelles sont les valeurs de ces attributs, et ce pour chaque élément avec lequel vous interagirez dans vos tests automatisés

Grâce à ça, vous remplissez toutes les cases d’un bon sélecteur puisqu’ils seront courts (vous ciblez directement le bon élément, donc un seul étage), uniques (les valeurs que vous avez définies), et robustes (vous êtes indépendants de l’architecture du DOM). Ainsi, même si un élément devait changer de position, votre sélecteur associé serait toujours valide !

Et le petit bonus avec cette méthode, c’est que vous n’avez plus besoin d’attendre que la feature soit implémentée pour coder les tests automatisés : vous avez déjà tout à disposition !

La cheatsheet

Je propose ici une cheatsheet sur les sélecteurs CSS et XPath que j’ai indiqué ci-dessus : encore une fois, l’objectif n’est pas d’être exhaustif, mais plutôt d’indiquer ceux qu’il faut connaître par coeur pour couvrir plus de 95% de vos besoins d’automaticien.

css_xpath_cheatsheet

Ce qu’il faut retenir

Un bon sélecteur doit être court, unique, et robuste face aux évolutions logiciels
Les sélecteurs CSS sont rapides, pratiques, et lisibles
Les sélecteurs XPath sont puissants, mais moins lisibles
Créez vos propres attributs dédiés aux tests automatisés