Améliorer la performance des tests Selenium

L'automatisation des tests est une bonne chose pour

* améliorer les délais de mise en production
* diminuer le coût des campagnes de tests de régression
* diminuer réduire la taille et le coût de rétention des releases (voir principe #6 de SAFe)
* mettre en place sa chaîne d'intégration continue (CI - Continuous Integration) et le test en continu qui va de pair
* etc.

Cependant, sur l'automatisation des tests de pages Web (avec Selenium), on se retrouve souvent confronté à des phénomènes de lenteurs.

Voici quelques astuces pour les réduire :

## Choix du sélecteur de widget

### Méthode XPath

Cette méthode est la plus flexible. Elle consiste à définir une chaîne de recherche que l'on peut optimiser par la position de l'objet dans le DOM. Ainsi, si l'objet recherché devait changer d'emplacement dans la page, il serait toujours trouvé tant que les critères d'identification restent valides.

Le revers de la médaille de cette flexibilité est évidemment la lenteur du mécanisme, ce qui fait de cette méthode la plus lente. Aussi, avec la maturité de la page pourrait-on imaginer une modification de la méthode de sélection des objets qui soit plus rapide.

* https://www.softwaretestinghelp.com/using-selenium-xpath-and-other-locators-selenium-tutorial-5/
* https://www.softwaretestinghelp.com/locate-elements-in-chrome-ie-selenium-tutorial-7/

### Méthode CSS

Comme pour le XPath, la méthode de sélection CSS s'appuie sur une chaîne de recherche qui sera plus rapide que le XPath [Haeffner] car il se base sur l'identification des objets CSS. Par ailleurs, le XPath ne fonctionne pas sur tous les navigateurs de la même façon voire est inexistant sur IE et par conséquent, Selenium fournit sa propre librairie de recherche de XPath [nilesh 2015].

En contre partie, la recherche CSS est évidemment moins flexible car la recherche de chaînes contenant un texte n'est plus possible. Par ailleurs, la performance dépend de bien des situations et peut aussi faire pencher celle-ci en faveur de XPath [Minakov 18].

Cette subtilité tend à pousser les Développeurs à utiliser le XPath,

* tant sur le temps d'ingénierie qui vient faire l'économie d'un test de performance
* que sur la maintenabilité du script (la chaîne de sélection est plus générique)
* ou sur les compétences : un point technique en moins à assimiler pour parvenir à ses fins

https://www.softwaretestinghelp.com/css-selector-selenium-locator-selenium-tutorial-6/

### Méthode par identifiant direct

Cette méthode est basée sur l'ajout d'un attribut "ID" dans la balise de l'objet HTML par le Développeur. C'est la plus rapide concernant la récupération de l'objet à manipuler, mais elle nécessite un bon niveau de communication entre les Développeurs et les Testeurs afin d'obtenir la présence systématique des ID et leur immuabilité (voir principe "Ouvert / Fermé").

### Cas de Angular

Angular ne fonctionne pas sur le paradigme du chemin dans la page web [mtu 2019], ce qui rend Selenium difficilement exploitable avec cette technologie et pousse le Testeur à utiliser la librairie Protractor.

## Réaliser de petits tests

Faire de petits scénarios de tests favorisera

* des scénarios plus facile à fiabiliser
* l'unicité d'objectif qui évitera la vérification de points annexes
* qu'un même point soit testé dans plusieurs scénarios

## Waits explicites

Il existe deux moyens pour attendre qu'un objet HTML soit disponible et continuer les actions d'un scénario de test :

* les attentes implicites

* les attentes explicites

Les attentes implicites sont basées sur l'instruction Selenium implicitlyWait().

```
WebDriver driver = new FirefoxDriver();
driver.manage().timeouts().**implicitlyWait**(10, TimeUnit.SECONDS);
driver.get("http://somedomain/url\_that\_delays\_loading");
WebElement myDynamicElement = driver.findElement(By.id("myDynamicElement"));

```

Cette approche n'est pas très efficace car elle ne fonctionne que dans certains cas et ne prend pas en considération la lenteur relative de certaines actions par rapport à d'autres [Aiquel 2018].

L'attente explicite avec l'instruction wait() peut se faire au cas par cas :

```
WebDriverWait wait = new WebDriverWait(driver, 10);

WebElement element = wait.until(ExpectedConditions.elementToBeClickable(By.id(“someid”)));

```

Elle permet un meilleurs ajustement des temps d'attente en fonction des éléments. Cette approche est à préférer à la précédente notamment car

* le temps d'exécution global du script sera plus court.

* les tests sont mieux documenté avec un comportement défini.

[Evans 2018] [Aiquel 2018]

## Pages lourdes

Lorsque certaines pages sont lourdes à charger, le temps d'exécution du script sera forcément ralenti. Pour améliorer les performances du script, il sera ainsi appréciable de faire en sorte que les images ne soient pas chargées lorsqu'un script est lancé.

Une fois encore, cette option dépendra des relations avec les Développeurs qui coderont l'activation pour le chargement des images.

## Navigateurs Headless

On peut aussi avoir recours à des navigateurs "Headless", littéralement, "sans tête" : toute interface graphique est éliminée, ce qui accélère les traitements [Nourissier 2018]. Le premier navigateur sans tête fut PhantomJS qui est maintenant abandonné [Slobodin 2017] et depuis Chrome 60 et Firefox 56, ces navigateurs intègrent se mode sans tête.

Voici quelques autres navigateurs sans tête :

* SlimerJS
* TrifleJS
* HTMLUnit driver

En plus d'améliorer les performances, l'utilisation de tels navigateurs est rendue possible sur des serveurs dénués de capacités graphiques et faciliter ainsi le lancement des tests dans une chaine d'intégration continue et facilite le multi-tâche [Boyarsky 2019].

## Pré-configuration des cookies

Si le script de test est capable de positionner certaines valeurs dans les cookies, l'application à tester pourra alors éviter certaines étapes et faire gagner du temps au scénario. On peut penser par exemple à récupérer un cookie de session pour éviter de repasser par l'étape d'identification.

## Exécution en parallèle

Concevoir des scénarios de tests isolables et répétables vient faciliter l'exécution en parallèle des tests et réduire le temps d'exécution. Ces critères rejoignent le critère FIRST [Kumar 2018].

## Driver Chrome (ou Firefox?)

Si on compare le taux d'erreur des navigateurs, on pourrait noter que Chrome est meilleur, mais cela dépendra au final de ses utilisateurs, des pages réalisées/utilisées et des navigateurs les plus utilisés [Advolodkin 2018].