WebDriver BiDi : l'avenir de l'automatisation multinavigateur

Dans notre article précédent, nous avons examiné les protocoles d'automatisation existants, à savoir WebDriver "Classic" et Chrome DevTools Protocol (CDP), ainsi que leurs avantages et contraintes respectifs.

Découvrez WebDriver BiDi, l'avenir de l'automatisation des navigateurs ! Il s'agit d'un nouveau protocole d'automatisation standard pour navigateur en cours de développement. Il vise à combiner le meilleur de WebDriver classique et de CDP. WebDriver BiDi promet une communication bidirectionnelle, ce qui la rend rapide par défaut et offre des commandes de bas niveau.

WebDriver BiDi
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

L'objectif de WebDriver BiDi est de vous permettre d'écrire des tests à l'aide de vos outils préférés et de les automatiser dans n'importe quel navigateur ou pilote, ce qui vous offre une flexibilité totale.

La vision derrière WebDriver BiDi.
Le concept de WebDriver BiDi

Standardisation

Le groupe de travail WebDriver BiDi est composé d'un groupe diversifié de fournisseurs de navigateurs, de projets d'automatisation des navigateurs Open Source et d'entreprises proposant des solutions d'automatisation des navigateurs. Cette collaboration garantit un avenir prometteur pour l'automatisation des navigateurs.

Le groupe de travail WebDriver BiDi
Groupe de travail BiDi WebDriver

Le travail est principalement effectué dans ce dépôt GitHub. Des réunions mensuelles sont organisées avec les principaux fournisseurs de navigateurs pour communiquer sur l'avancement du projet et discuter de spécificités douteuses ou inconnues. Le groupe de travail inter-entreprises s'assure que les décisions sont alignées sur toutes les parties prenantes.

Établir et implémenter un nouveau protocole n'est pas une mince affaire. Cela nécessite un effort concerté de la part de différents fournisseurs qui collaborent et travaillent ensemble. Ce processus implique les opérations suivantes:

  • Spécification: processus de demande de commentaires (RFC) permettant de recueillir des commentaires sur la proposition.
  • Validation: série de tests pouvant être exécutés sur différentes plates-formes, servant de source de référence pour toutes les implémentations.
  • Implémentation: les navigateurs implémentent les protocoles conformément aux spécifications et réussissent les tests de vérification.

Difficultés

Dans cette section, nous aborderons les difficultés liées à l'implémentation de WebDriver BiDi, dans la mesure où elle cherche à trouver un équilibre entre compatibilité, facilité d'utilisation et implémentation.

Au-delà d'un clone CDP: adopter la compatibilité entre navigateurs

La plate-forme de données client, avec ses éléments spécifiques à Chrome et aux outils de développement, ne peut pas être répliquée directement dans la spécification WebDriver BiDi. Il serait impossible d'implémenter la CDP telle quelle pour d'autres navigateurs, ce qui rendrait inutile une spécification qui se contente de documenter la procédure à suivre.

Garantie de faible latence

WebDriver BiDi doit être conçu pour gérer une latence élevée sans compromettre les performances. Dans CDP, la latence est faible, car le client et le serveur sont presque toujours exécutés sur la même machine physique, ce qui n'est pas le cas dans WebDriver BiDi. Par conséquent, WebDriver BiDi doit réduire le nombre d'allers-retours requis entre le client et le serveur.

Privilégier l'ergonomie dans BiDi

Bien que les développeurs ne soient pas censés créer des clients BiDi WebDriver à partir de zéro, il est essentiel d'éviter de trop compliquer le protocole. Un BiDi trop complexe serait non seulement difficile à mettre en œuvre, mais aussi difficile à utiliser, ce qui entraverait l’adoption et l’utilisation.

Assurer l'implémentation de BiDi

WebDriver BiDi doit pouvoir être implémenté de façon réaliste, en tenant compte des limites des différents navigateurs. Par exemple, la conservation de tous les objets JavaScript jamais exposés aux clients par BiDi pourrait entraîner des fuites de mémoire, tandis que le fait de ne conserver aucun objet pourrait entraver le débogage et l'interaction avec le code JavaScript d'une page. Il est essentiel de trouver un équilibre permettant d'automatiser efficacement les navigateurs sans compromettre les performances.

Surmonter les défis

Dans cette section, nous allons évoquer les stratégies employées pour relever les défis liés à l'implémentation de l'outil BiDi de WebDriver.

Prototypage rapide

Relever le défi de la mise en œuvre est crucial pour la réussite de BiDi. Pour accélérer l'évolution de la spécification et des tests, nous avons adopté une approche de prototypage rapide à l'aide de NodeJS. Cela nous permet non seulement de tester différentes solutions, mais aussi de développer plus facilement des tests de plate-forme Web.

Concevoir en tenant compte des performances

Cette décision de conception est basée sur les performances, car dans certains cas, la latence est élevée dans WebDriver BiDi. Par exemple, lors de la récupération d'un ID et d'une valeur d'objet à partir du navigateur, WebDriver BiDi ne nécessite qu'un aller-retour, tandis que CDP en nécessite deux. En effet, WebDriver BiDi peut renvoyer l'ID et la valeur dans une seule réponse (le résultat ne doit pas être sérialisable au format JSON), alors que CDP doit les renvoyer séparément.

Mise en avant des tests de plate-forme Web (WPT)

Les tests de plate-forme Web jouent un rôle important dans le travail de BiDi. Actuellement couvert par WebDriver "Classic" et WebDriver BiDi, WPT sert de référence fiable pour toutes les implémentations. Ces tests sont conçus pour être exécutés et transmis dans différentes implémentations, ce qui garantit une exécution cohérente des protocoles entre les navigateurs, ce qui est essentiel au succès de WebDriver BiDi. Consultez le dernier résultat WPT dans le tableau de bord.

Quel est le plan et les progrès actuels ?

Consultez la feuille de route WebDriver BiDi pour comprendre l'orientation du projet. La feuille de route est un travail en cours et en constante évolution.

Reportez-vous aux derniers tests de plate-forme Web pour connaître l'état de la mise en œuvre dans les différents navigateurs, car ils servent de source de référence.

Suivez les étapes du projet pour suivre son avancement.

Découvrez les réussites de 2023 et tenez-vous informé des dernières nouveautés.

Compatibilité avec WebDriver BiDi: comment aider

Êtes-vous impatient de découvrir l'avenir de l'automatisation des navigateurs avec WebDriver BiDi ? Voici comment vous pouvez manifester votre soutien:

  • Participer aux premiers tests et adopter les nouvelles pratiques et contribuer à façonner l'avenir de WebDriver BiDi
  • Parlez-en autour de vous Partagez le projet sur les réseaux sociaux à l'aide du hashtag #WebDriverBiDi.
  • Demandez de l'aide. Envoyez une demande de fonctionnalité ou vérifiez auprès de vos outils préférés s'ils envisagent d'adopter WebDriverBiDi.
  • Participez au document RFC et donnez votre avis sur les API.

Questions fréquentes

WebDriver BiDi va-t-il remplacer Chrome DevTools Protocol (CDP) ?

Non. Les navigateurs basés sur Chromium continueront d'utiliser CDP à des fins de débogage, tandis que WebDriver BiDi est la nouvelle spécification qui répond aux besoins de test avec une API plus ergonomique.

Puisque Puppeteer utilise la plate-forme de données client, cela signifie-t-il que Puppeteer va être abandonné ?

Non. Toutefois, WebDriver BiDi va permettre à Puppeteer de devenir un outil d'automatisation multinavigateur.

Avez-vous une feuille de route publique ?

Oui, consultez notre feuille de route sur GitHub.