La naissance de l'automatisation des tests
Revenons aux années 1990, à l'époque de la naissance du navigateur Web. L'automatisation des tests n'est apparue en réalité que dans les années 2000, avec l'émergence des projets Selenium et WebDriver visant à relever les défis liés aux tests multi-navigateurs et multi-appareils.
Ces deux projets ont uni leurs forces en 2011 sous le nom de Selenium WebDriver, puis sont devenus norme W3C en 2018. Nous l'appelons généralement WebDriver ou WebDriver "classique".
L'automatisation des tests avant la version classique de WebDriver était assez complexe. La possibilité d'automatiser les tests sur navigateur a considérablement amélioré la qualité de vie des développeurs et des testeurs.
L'essor de JavaScript
Alors que le développement Web a évolué pour s'appuyer davantage sur JavaScript, de nouvelles solutions d'automatisation telles que WebdriverIO, Appium, Nightwatch, Protractor (obsolète), Testcafe, Cypress, Puppeteer et Playwright ont vu le jour.
Approches d'automatisation
De manière générale, ces outils peuvent être organisés en deux grands groupes, en fonction de la manière dont ils automatisent les navigateurs:
- Niveau élevé: outils qui exécutent JavaScript dans le navigateur. Par exemple, Cypress et TestCafe utilisent des API Web et Node.js pour exécuter des tests directement dans le navigateur. Fait intéressant : la première version de Selenium utilisait également la même approche.
- Niveau inférieur: outils qui exécutent des commandes à distance en dehors du navigateur. Lorsque des outils nécessitent un contrôle encore plus grand (par exemple, ouvrir plusieurs onglets ou simuler le mode de l'appareil), ils doivent exécuter des commandes à distance pour contrôler le navigateur via des protocoles. Les deux principaux protocoles d'automatisation sont WebDriver "Classic" et le CDP (Chrome DevTools Protocol).
Dans la section suivante, nous examinerons ces deux protocoles pour comprendre leurs points forts et leurs limites.
Comparaison entre WebDriver "Classic" et Chrome DevTools Protocol (CDP)
WebDriver "Classic" est une norme Web compatible avec les principaux navigateurs. Les scripts d'automatisation envoient des commandes via des requêtes HTTP à un serveur de pilotes, qui communique ensuite avec les navigateurs via des protocoles internes spécifiques à chaque navigateur.
Bien qu'il soit compatible avec plusieurs navigateurs et que ses API soient conçues pour les tests, il peut être lent et n'est pas compatible avec certaines commandes de bas niveau.
Par exemple, imaginez que vous disposez d'un script de test qui clique sur un élément await coffee.click();. Elle est traduite en une série de requêtes HTTP.
# WebDriver: Click on a coffee element
curl -X POST http://127.0.0.1:4444/session/:element_id/element/click
-H 'Content-Type: application/json'
-d '{}'
Le protocole des outils pour les développeurs Chrome, quant à lui, a été initialement conçu pour les outils pour les développeurs Chrome et le débogage, puis a été adopté par Puppeteer pour l'automatisation. La plate-forme de données client communique directement avec les navigateurs basés sur Chromium via des connexions WebSocket, ce qui permet de bénéficier de performances plus rapides et d'un contrôle de bas niveau.
Toutefois, il ne fonctionne qu'avec les navigateurs basés sur Chromium et ne constitue pas une norme ouverte. De plus, les API CDP sont relativement complexes. Dans certains cas, l'utilisation de CDP n'est pas ergonomique. Par exemple, travailler avec des iFrames hors processus demande beaucoup d'efforts.
Par exemple, un clic sur un élément await coffee.click(); se traduit par une série de commandes CDP.
// CDP: Click on a coffee element
// Mouse pressed
{
command: 'Input.dispatchMouseEvent',
parameters: {
type: 'mousePressed', x: 10.34, y: 27.1, clickCount: 1 }
}
// Mouse released
{
command: 'Input.dispatchMouseEvent',
parameters: {
type: 'mouseReleased', x: 10.34, y: 27.1, clickCount: 1 }
}
Quelles sont les commandes de niveau inférieur ?
À l'époque où la version classique de WebDriver était développée, les contrôles de bas niveau n'étaient pas nécessaires. Mais les temps ont changé, le Web est aujourd'hui bien plus performant, et les tests d'aujourd'hui exigent des actions plus précises.
Étant donné que CDP a été conçu pour répondre à tous les besoins de débogage, il est compatible avec davantage de commandes de bas niveau que la version classique de WebDriver. Il est capable de gérer des fonctionnalités telles que:
- Capturer les messages de la console
- Interception des requêtes réseau
- Simuler le mode de l'appareil
- Simuler la géolocalisation
- Et bien plus !
Ces opérations n'étaient pas possibles dans WebDriver "Classic" en raison de leur architecture différente. WebDriver "Classic" est basé sur HTTP, ce qui rend difficile l'abonnement et l'écoute des événements du navigateur. La plate-forme CDP, en revanche, est basée sur WebSocket et accepte par défaut la messagerie bidirectionnelle.
Prochaine étape: WebDriver BiDi
Voici un récapitulatif des points forts de WebDriver "Classic" et du CDP:
| WebDriver "Classic" | Protocole des outils pour les développeurs Chrome (CDP) |
|---|---|
| La meilleure compatibilité multinavigateur | Messagerie rapide et bidirectionnelle |
| Norme W3C | Offre un contrôle de bas niveau |
| Conçue pour les tests |
WebDriver BiDi vise à combiner les meilleurs aspects de WebDriver "Classic" et CDP. Il s'agit d'un nouveau protocole d'automatisation standard des navigateurs en cours de développement.
En savoir plus sur le projet WebDriver BiDi : son fonctionnement, sa vision et le processus de standardisation