Retour dans le temps: évolution de l'automatisation des tests

Jecelyn Yeen

Maksim Sadym

Naissance de l'automatisation des tests

Revenons aux années 1990, lorsque le navigateur Web est né. L'automatisation des tests n'est devenue réalité qu'au début des années 2000, avec l'émergence des projets Selenium et WebDriver pour relever les défis des tests multinavigateur et multiappareils.

Ces deux projets ont fusionné en 2011 sous le nom de Selenium WebDriver et sont devenus une norme W3C en 2018. Nous l'appelons généralement WebDriver ou WebDriver "classique".

L'automatisation des tests avant WebDriver "classique" était assez délicate. La possibilité d'automatiser les tests dans les navigateurs a considérablement amélioré la qualité de vie des développeurs et des testeurs.

L'essor de JavaScript

À mesure que le développement Web s'est appuyé 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 regroupés en deux grands groupes en fonction de la manière dont ils automatisent les navigateurs:

• Haut niveau: outils qui exécutent JavaScript dans le navigateur. Par exemple, Cypress et TestCafe exploitent les API Web et Node.js pour exécuter des tests directement dans le navigateur. Fait amusant : la première version de Selenium utilisait également la même approche.
• Niveau bas: outils qui exécutent des commandes à distance en dehors du navigateur. Lorsque les outils nécessitent un contrôle encore plus strict, par exemple pour ouvrir plusieurs onglets ou simuler le mode 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 protocole CDP (Chrome DevTools Protocol).

Dans la section suivante, nous allons examiner ces deux protocoles pour comprendre leurs points forts et leurs limites.

WebDriver "classique" par rapport au protocole Chrome DevTools (CDP)

WebDriver "Classic" est une norme Web compatible avec tous 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 aux navigateurs.

Bien qu'il offre une excellente compatibilité multinavigateur 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, imaginons que vous disposiez d'un script de test qui clique sur un élément await coffee.click();. Il est converti 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 '{}'

En revanche, le protocole CDP (Chrome DevTools Protocol) a été initialement conçu pour les outils pour les développeurs Chrome et le débogage, mais a été adopté par Puppeteer pour l'automatisation. CDP communique directement avec les navigateurs basés sur Chromium via des connexions WebSocket, ce qui offre des performances plus rapides et un contrôle de bas niveau.

Cependant, il ne fonctionne qu'avec les navigateurs basés sur Chromium et n'est pas une norme ouverte. De plus, les API CDP sont relativement complexes. Dans certains cas, l'utilisation d'un 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(); est traduit en 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 }
}

Quels sont les contrôles de bas niveau ?

À l'époque où WebDriver "classique" a été développé, il n'était pas nécessaire de contrôler le niveau bas. Mais les temps ont changé, le Web est beaucoup plus performant et les tests exigent aujourd'hui des actions plus précises.

Étant donné que CDP a été conçu pour répondre à tous les besoins de débogage, il accepte davantage de commandes de bas niveau que WebDriver "classique". Il peut gérer des fonctionnalités telles que:

• Capturer les messages de la console
• Interception des requêtes réseau
• Simuler le mode Appareil
• Simuler la géolocalisation
• Et bien plus !

Ces fonctionnalités n'étaient pas possibles dans WebDriver "classique" en raison de l'architecture différente. WebDriver "classique" est basé sur HTTP, ce qui rend l'abonnement et l'écoute des événements du navigateur difficiles. CDP, en revanche, est basé sur WebSocket et prend en charge la messagerie bidirectionnelle par défaut.

Étape suivante: WebDriver BiDi

Voici un récapitulatif des points forts de WebDriver "classique" et de CDP:

WebDriver BiDi vise à combiner les meilleurs aspects de WebDriver "Classic" et de CDP. Il s'agit d'un nouveau protocole d'automatisation de navigateur standard actuellement en cours de développement.

Découvrez le projet WebDriver BiDi, son fonctionnement, sa vision et son processus de normalisation.