WebDriver BiDi – Die Zukunft der browserübergreifenden Automatisierung

In unserem vorherigen Artikel haben wir die vorhandenen Automatisierungsprotokolle, nämlich WebDriver „Classic“ und das Chrome DevTools Protocol (CDP) sowie ihre jeweiligen Vor- und Nachteile untersucht.

Jetzt mit WebDriver BiDi, der Zukunft der Browserautomatisierung, starten. Es handelt sich dabei um ein neues Standardprotokoll zur Browserautomatisierung, das sich derzeit noch in der Entwicklung befindet und das Beste von WebDriver Classic und CDP kombiniert. WebDriver BiDi verspricht bidirektionale Kommunikation, damit diese standardmäßig schnell ist, und verfügt über eine Fülle an Low-Level-Kontrollmöglichkeiten.

WebDriver BiDi
WebDriver Classic Chrome DevTools Protocol (CDP)
Beste browserübergreifende Unterstützung Schnelle, bidirektionale Nachrichtenfunktion
W3C-Standard Bietet Low-Level-Kontrolle
Für Tests entwickelt

Die Vision von WebDriver BiDi besteht darin, Tests mit Ihren bevorzugten Tools zu erstellen und diese in jedem Browser und Treiber zu automatisieren, sodass Sie volle Flexibilität haben.

Die Vision hinter WebDriver BiDi.
Die Vision hinter WebDriver BiDi

Standardisierung

Die WebDriver BiDi Working Group umfasst verschiedene Browseranbieter, Open-Source-Projekte zur Browserautomatisierung und Unternehmen, die Lösungen zur Browserautomatisierung anbieten. Diese Zusammenarbeit sorgt für eine vielversprechende Zukunft bei der Browserautomatisierung.

Arbeitsgruppe zu WebDriver BiDi
The WebDriver BiDi Working Group

Die Arbeit erfolgt hauptsächlich in diesem GitHub-Repository. Es finden monatliche Meetings mit allen großen Browser-Anbietern statt, in denen die tatsächlichen Fortschritte gemeldet und diskutierte und unbekannte Besonderheiten diskutiert werden. Die unternehmensübergreifende Arbeitsgruppe stellt sicher, dass Entscheidungen mit allen Stakeholdern abgestimmt werden.

Die Einrichtung und Implementierung eines neuen Protokolls ist keine leichte Aufgabe. Es erfordert koordinierte Anstrengungen verschiedener Zulieferunternehmen, die zusammenarbeiten und zusammenarbeiten. Der Prozess umfasst:

  • Spezifikation: Eine Anforderung für Kommentare (RFC-Prozess), um Feedback zum Vorschlag zu sammeln.
  • Überprüfung: Eine Reihe von Tests, die plattformübergreifend ausgeführt werden können und als Datenquelle für alle Implementierungen dienen.
  • Implementierung: Browser implementieren die Protokolle gemäß der Spezifikation und bestehen die Überprüfungstests.

Challenges

In diesem Abschnitt gehen wir auf die Herausforderungen ein, die sich bei der Implementierung von WebDriver BiDi ergeben, da es ein Gleichgewicht zwischen Kompatibilität, Nutzerfreundlichkeit und Implementierbarkeit erreichen soll.

Über einen CDP-Klon hinaus: Browserübergreifende Kompatibilität

Das CDP kann mit seinen für Chrome und Entwicklertools spezifischen Elementen nicht direkt in der WebDriver BiDi-Spezifikation repliziert werden. Die Implementierung von CDP im aktuellen Zustand wäre für andere Browser nicht machbar, da eine Spezifikation, die lediglich dokumentiert, wie eine solche Vorgehensweise beschrieben wird, unnötig macht.

Niedrige Latenz sicherstellen

WebDriver BiDi muss hohe Latenz ohne Leistungseinbußen bewältigen. Bei CDP ist die Latenz niedrig, da Client und Server fast immer auf demselben physischen Computer ausgeführt werden. Bei WebDriver BiDi ist dies jedoch nicht der Fall. Daher muss WebDriver BiDi die Anzahl der Umläufe zwischen Client und Server minimieren.

Ergonomie priorisieren

Von Entwicklern wird zwar nicht erwartet, WebDriver BiDi-Clients von Grund auf neu zu erstellen, es ist jedoch wichtig, das Protokoll nicht zu kompliziert zu gestalten. Ein übermäßig komplexes BiDi wäre nicht nur schwer zu implementieren, sondern auch schwer zu handhaben, was die Akzeptanz und Nutzung behindert.

Implementierungsfähigkeit von BiDi sicherstellen

WebDriver BiDi muss unter Berücksichtigung der Einschränkungen verschiedener Browser realisierbar sein. Wenn beispielsweise alle JavaScript-Objekte aufbewahrt werden, die jemals über BiDi den Clients zugänglich gemacht wurden, kann es zu Speicherlecks kommen, ohne dass dies das Debugging und die Interaktion mit dem JavaScript einer Seite beeinträchtigen würde. Es ist entscheidend, ein Gleichgewicht zu finden, das eine effektive Browserautomatisierung ermöglicht, ohne die Leistung zu beeinträchtigen.

Herausforderungen meistern

In diesem Abschnitt erörtern wir die Strategien, die zur Bewältigung der Herausforderungen bei der Implementierung von WebDriver BiDi eingesetzt werden.

Rapid Prototyping

Für den Erfolg von BiDi ist es entscheidend, sich mit den Herausforderungen der Umsetzbarkeit zu befassen. Um den Fortschritt bei der Spezifikation und den Tests zu beschleunigen, haben wir einen Rapid Prototyping-Ansatz mit NodeJS eingeführt. So können wir nicht nur mit verschiedenen Lösungen experimentieren, sondern auch die Entwicklung von Webplattform-Tests.

Leistung im Blick behalten

Diese Designentscheidung hängt von der Leistung ab, da die Latenz in WebDriver BiDi in einigen Fällen hoch ist. Beim Abrufen einer Objekt-ID und eines Werts aus dem Browser benötigt WebDriver BiDi nur einen Roundtrip, während für CDP zwei erforderlich sind. Dies liegt daran, dass WebDriver BiDi sowohl die ID als auch den Wert in einer einzelnen Antwort zurückgeben kann (das Ergebnis sollte nicht JSON-serialisierbar sein), während CDP sie separat zurückgeben muss.

Betonung auf Web Platform Tests (WPT)

Webplattform-Tests spielen bei BiDi eine wichtige Rolle. WPT deckt derzeit WebDriver Classic und WebDriver BiDi ab und dient als zuverlässige Referenz für alle Implementierungen. Diese Tests sind so konzipiert, dass sie in verschiedenen Implementierungen ausgeführt und bestanden werden. So ist eine einheitliche browserübergreifende Protokollausführung sichergestellt, die für den Erfolg von WebDriver BiDi von entscheidender Bedeutung ist. Sehen Sie sich das neueste WPT-Ergebnis im Dashboard an.

Wie sieht der Plan und der aktuelle Fortschritt aus?

Sehen Sie sich die WebDriver BiDi-Roadmap an, um die Richtung des Projekts zu verstehen. Die Roadmap ist in der Entwicklung und wird sich ständig weiterentwickeln.

Den Implementierungsstatus in den verschiedenen Browsern finden Sie in den aktuellen Webplattform-Tests, da er als zentrale Datenquelle dient.

Informieren Sie sich über die Projektmeilensteine, um ihren Fortschritt zu überwachen.

Entdecke die Erfolge des Jahres 2023 und bleib über die neuesten Entwicklungen auf dem Laufenden.

Unterstützung von WebDriver BiDi: So können Sie helfen

Seien Sie gespannt auf die Zukunft der Browserautomatisierung mit WebDriver BiDi? So kannst du deine Unterstützung zeigen:

  • Anfänger und Tester sein und die Zukunft von WebDriver BiDi mitgestalten
  • Weitersagen: Das Projekt in den sozialen Medien unter dem Hashtag #WebDriverBiDi teilen.
  • Bitten Sie um Unterstützung. Reichen Sie eine Funktionsanfrage ein oder informieren Sie sich bei Ihren Lieblingstools über ihre Pläne für die Einführung von WebDriverBiDi.
  • Am RFC teilnehmen und Feedback zu den APIs geben

Häufige Fragen

Wird WebDriver BiDi das Chrome DevTools Protocol (CDP) ersetzen?

Nein. Chromium-basierte Browser verwenden weiterhin CDP für Debugging-Zwecke, während WebDriver BiDi die neue Spezifikation ist, um die Testanforderungen mit einer ergonomischeren API zu erfüllen.

Bedeutet dies, dass Puppeteer eingestellt wird, da Puppeteer CDP verwendet?

Nein. Mit WebDriver BiDi wird Puppeteer jedoch zu einem browserübergreifenden Automatisierungstool.

Haben Sie eine öffentliche Roadmap?

Ja, sehen Sie sich unsere Roadmap auf GitHub an.