Événements WebDriver BiDi pour une automatisation stable
Comprendre les sessions, événements et limites de transport WebDriver BiDi pour une automatisation maintenable.
Vous voulez la documentation structurée pour Démarrage ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
WebDriver BiDi fournit un canal standard dans les deux sens. Le client envoie une commande tandis que le navigateur publie un événement, ce qui permet d’observer navigation, journaux, réseau et contextes sans transformer chaque transition en délai arbitraire. Un événement est une observation du navigateur, pas la preuve qu’une application ou un service a accepté une opération.
Une exécution BiDi se conçoit comme un petit système : session négociée, transport attribué, abonnements explicites et assertions visibles pour l’utilisateur. Ces limites clarifient le diagnostic. Le guide de démarrage Playwright présente le cycle de vie du navigateur et la validation des interactions traite les éléments qui dépassent un événement.
Cette séparation aide la maintenance. Un test peut observer une navigation, un message de console ou une réponse pendant que l’application choisit encore son affichage. Une réponse correcte du pilote ne prouve pas que le serveur a accepté les données. Nommer séparément l’observation et le résultat distingue une régression de page, de pilote, de transport ou de service.
Ce que WebDriver BiDi change
WebDriver classique est orienté requête : le client envoie une commande puis reçoit une réponse. BiDi ajoute une connexion durable afin que le navigateur envoie des événements sans nouvelle requête. La spécification W3C WebDriver BiDi définit commandes, événements et contextes de navigation.
Un événement ne remplace pas une assertion. log.entryAdded montre que le navigateur a observé une entrée de console, pas que le serveur a enregistré quelque chose ou que le parcours a réussi. Un événement réseau décrit une catégorie de requête ou de réponse, alors que la page peut afficher une erreur. Associez l’événement à l’assertion minimale du résultat attendu.
BiDi sépare observation et implémentation. Le client s’abonne à des types nommés et peut limiter un contexte de navigation. C’est plus lisible que de collecter chaque message puis de chercher après coup. Un abonnement n’est pas une frontière de confidentialité : la politique du test doit aussi encadrer URL, en-têtes, arguments et contenu. Ne gardez que les métadonnées utiles.
Le protocole évolue et le support varie selon le navigateur et le pilote. Une session peut se connecter puis refuser une commande, omettre un champ optionnel ou se fermer si une fonction manque. Enregistrez capacités négociées et versions. Classez le support absent séparément d’un échec applicatif afin d’éviter un délai d’attente trompeur.
Négocier une session que vous maîtrisez
La création de session déclare les attentes et fournit les identifiants réutilisés ensuite. Gardez ensemble configuration, profil, politique de journalisation et capacités demandées. Une capacité demandée n’est pas une garantie d’implémentation. Lisez la réponse, conservez les valeurs acceptées et décidez à partir d’elles.
Les contextes sont une autre limite de propriété. Un onglet, une iframe et une fenêtre peuvent avoir des identifiants différents. Conservez ces identifiants à leur création ou découverte. Avec plusieurs contextes, envoyez chaque événement au cas qui possède le contexte et ignorez les notifications étrangères pour éviter les courses.
Le fixture doit définir quand la session est prête et quand elle n’est plus utilisable. Il peut exiger une négociation réussie, un contexte connu et un accusé d’abonnement. À l’arrêt, bloquez les nouvelles actions, retirez les écouteurs, demandez la fin prise en charge puis fermez le transport. Une voie finally reste nécessaire lorsqu’un callback échoue séparément.
Rendez la configuration déterministe. Chaque worker possède un profil et un chemin d’artefacts ; notez navigateur, pilote et version du protocole. Ne réutilisez pas une session inconnue. La documentation bidirectionnelle de Selenium décrit le modèle côté client ; l’équipe garde la responsabilité des données et du nettoyage serveur.
S’abonner sans perdre le contexte
Les abonnements doivent répondre à une question précise. Pour une erreur de page, filtrez l’événement de journal par contexte. Pour une navigation, gardez l’identifiant, la catégorie d’URL et l’heure autorisée. Filtrer tôt réduit le travail et évite de capturer l’activité des autres pages.
Le gestionnaire doit rester presque sans effets de bord. Il peut ajouter un enregistrement borné, résoudre une attente nommée ou avancer une machine d’état. Il ne doit pas cliquer, soumettre, modifier le stockage ou ouvrir une session. Un événement ne déclenche ainsi ni action double ni course réentrante.
L’ordre n’a de valeur que dans les garanties du protocole et du pilote. Une requête peut arriver avant l’affichage du résultat, et un journal après le retour de l’action. Utilisez l’événement comme marqueur puis attendez l’état visible. Si plusieurs fins sont valides, nommez-les et classez la première.
Les événements tardifs sont normaux pendant l’arrêt. Marquez la session en fermeture avant de retirer les écouteurs et ignorez les messages après l’état final. Limitez la file et signalez un débordement. Si un abonnement est refusé, notez son nom et n’utilisez un repli approuvé que s’il existe ; sinon signalez la capacité manquante.
Traiter le transport comme un cycle de vie
Le transport BiDi est une connexion durable qui porte commandes, réponses et événements spontanés. Le client corrèle chaque réponse à son identifiant et distribue les événements aux abonnés. Gardez cette corrélation dans la bibliothèque ; le test reçoit un résultat nommé plutôt que des trames brutes.
Une coupure peut survenir avec une commande en attente ou pendant des événements. Distinguez fermeture propre, erreur de transport, crash du navigateur et délai applicatif. Reconnecter n’est pas toujours sûr : répéter un envoi peut doubler une opération. Ne répétez qu’une préparation idempotente selon une règle explicite et créez une session neuve si l’ancien état est inconnu.
Prévoyez la pression sur la file. Beaucoup de journaux ou d’événements réseau peuvent masquer celui qui compte. Filtrez à l’abonnement, bornez les enregistrements et indiquez les pertes. Masquez les valeurs avant archivage, surtout URL avec paramètres, en-têtes et arguments. Le protocole fournit des données sans décider de leur conservation.
Les délais de transport doivent identifier la couche bloquée. Délai de réponse de commande, attente d’événement et attente de page ne signifient pas la même chose. Incluez nom, contexte autorisé, état de connexion et dernière catégorie observée. Ne convertissez pas une déconnexion en délai de page générique.
Construire des assertions stables pilotées par événements
Commencez par un résultat déclaré et un petit modèle d’état. Pour un paiement autorisé : panier synthétique, envoi, statut visible et échec borné. BiDi observe navigation ou réponse, mais l’assertion stable est le statut lisible par l’utilisateur. Nommer le résultat empêche l’accumulation de signaux pratiques.
Utilisez une attente par transition et donnez-lui un nom sémantique. Une attente contextCreated se termine à l’arrivée du contexte prévu ; une autre attend l’en-tête de confirmation. Les prédicats lisent sans modifier, et leurs limites viennent de la configuration. Gardez le nom de la condition dans le rapport si la limite change.
L’artefact d’échec conserve la première condition absente. Notez capacités acceptées, action, catégorie d’événement, propriété du contexte et versions, avec une observation masquée. Une capture peut convenir à un fixture synthétique approuvé, mais une page authentifiée complète n’est pas nécessaire. Le cycle de vie BrowserContext de Puppeteer propose une séparation similaire.
Exercez les chemins négatifs. Retirez un signal de préparation dans un fixture synthétique et vérifiez un délai borné qui le nomme. Simulez un abonnement refusé ou un transport fermé et classez le résultat comme problème d’environnement ou de capacité, jamais comme succès. L’exercice n’utilise ni données privées ni compte réel.
Utiliser BotBrowser avec des limites claires
BotBrowser peut fournir des contextes isolés et des profils reproductibles pour des exécutions autorisées qui observent WebDriver BiDi. Cela aide à comparer les mêmes entrées et à attribuer le profil. BotBrowser ne met pas en œuvre le protocole WebDriver BiDi, n’ajoute pas de commandes ou d’événements absents et ne garantit pas la compatibilité du pilote, du navigateur, du transport ou de l’application. La pile choisie reste responsable du protocole et du résultat serveur.
L’isolation sépare stockage et état synthétiques, mais n’autorise pas un test par elle-même. Définissez les pages, données et champs lisibles. Attribuez profils et artefacts au worker et fermez la session via son cycle pris en charge. Un départ reproductible facilite la comparaison sans garantir un événement ni l’acceptation d’un service.
Avec BotBrowser et un pilote BiDi, notez la combinaison réelle et les capacités acceptées. Si une commande manque, attribuez la limite au composant qui l’a refusée. Ne confondez pas isolation du profil et conformité du protocole, ni profil reproductible et transaction achevée. Validation produit et conformité restent séparées.
Liste de revue pour les équipes BiDi
Avant l’exécution, confirmez propriétaire de session, profil, transport, capacités et abonnements. Choisissez le contexte de chaque assertion et les données autorisées dans les journaux. Déclarez l’état visible de fin et les événements qui l’appuient. Le fixture devient ainsi vérifiable.
Pendant l’exécution, corrélez chaque réponse et routez chaque événement vers un gestionnaire conscient du contexte. Gardez les gestionnaires bornés et sans effets de bord. Séparez commandes non prises en charge, coupures, files pleines et délais de page. Un repli doit être explicitement sûr ; créez une session neuve si l’ancienne est invérifiable.
Après l’exécution, fermez écouteurs et session même après une assertion échouée. Gardez seulement l’évidence synthétique autorisée, notamment la première condition manquante et les capacités acceptées. Comparez le résultat et le tuple de compatibilité, pas les horaires accidentels. Rejouez les contrôles après tout changement de navigateur ou de pilote.
Le contrat durable est simple : BiDi transporte commandes et observations, le fixture gère session et transport, et l’application définit la fin. Séparer ces responsabilités rend l’échec précis sans transformer un événement en garantie métier.
Les équipes peuvent conserver ce contrat près de chaque parcours : commande de départ, événement observé, contexte propriétaire, assertion lisible et repli quand l’événement manque. Les trames brutes sont inutiles ; il faut assez de contexte pour distinguer régression, capacité absente et connexion perdue.
Le relevé doit aussi indiquer le nettoyage. Un contexte enfant a un propriétaire, un abonnement un moment de retrait et un artefact une frontière de données synthétiques. Cela évite qu’un événement tardif atteigne un autre test ou qu’un profil échoué modifie le suivant. BiDi fournit le mécanisme ; les propriétaires fixent la politique.
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.