Die Geburtsstunde der Testautomatisierung
Kehren wir zurück in die 1990er-Jahre, als der Webbrowser erfunden wurde. Die Testautomatisierung wurde erst in den 2000er-Jahren mit den Projekten Selenium und WebDriver Realität, um browser- und geräteübergreifende Tests zu ermöglichen.
Diese beiden Projekte wurden 2011 als Selenium WebDriver zusammengeführt und 2018 zum W3C-Standard. Wir bezeichnen es normalerweise als WebDriver oder WebDriver „Classic“.
Die Testautomatisierung vor WebDriver „Classic“ war ziemlich schwierig. Die Möglichkeit, Browsertests zu automatisieren, hat die Qualität der Arbeit von Entwicklern und Testern erheblich verbessert.
Der Aufstieg von JavaScript
Da die Webanwendungsentwicklung immer mehr auf JavaScript basiert, sind neue Automatisierungslösungen wie WebdriverIO, Appium, Nightwatch, Protractor (veraltet), Testcafe, Cypress, Puppeteer und Playwright entstanden.
Ansätze zur Automatisierung
Diese Tools lassen sich grob in zwei große Gruppen unterteilen, je nachdem, wie sie Browser automatisieren:
- Hochrangig: Tools, die JavaScript im Browser ausführen. Cypress und TestCafe nutzen beispielsweise Web-APIs und Node.js, um Tests direkt im Browser auszuführen. Fun Fact: Auch die erste Version von Selenium verwendete diesen Ansatz.
- Niedrige Ebene: Tools, die Remotebefehle außerhalb des Browsers ausführen. Wenn Tools eine noch genauere Steuerung erfordern, z. B. das Öffnen mehrerer Tabs oder die Simulation des Gerätemodus, müssen sie Remote-Befehle ausführen, um den Browser über Protokolle zu steuern. Die beiden wichtigsten Automatisierungsprotokolle sind WebDriver „Classic“ und Chrome DevTools Protocol (CDP).
Im nächsten Abschnitt sehen wir uns diese beiden Protokolle an, um ihre Stärken und Einschränkungen zu verstehen.
„Klassischer“ WebDriver im Vergleich zum Chrome DevTools Protocol (CDP)
WebDriver „Classic“ ist ein Webstandard, der von allen gängigen Browsern unterstützt wird. Automatisierungsscripts senden über HTTP-Anfragen Befehle an einen Treiberserver, der dann über interne, browserspezifische Protokolle mit Browsern kommuniziert.
Es bietet zwar eine hervorragende browserübergreifende Unterstützung und seine APIs sind für Tests konzipiert, kann aber langsam sein und unterstützt einige Steuerelemente auf niedriger Ebene nicht.
Angenommen, Sie haben ein Testscript, das auf ein Element await coffee.click(); klickt. Sie wird in eine Reihe von HTTP-Anfragen umgewandelt.
# 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 '{}'
Das Chrome DevTools Protocol (CDP) wurde hingegen ursprünglich für Chrome DevTools und das Debuggen entwickelt, aber von Puppeteer für die Automatisierung übernommen. CDP kommuniziert über WebSocket-Verbindungen direkt mit Chromium-basierten Browsern und bietet so eine schnellere Leistung und eine Low-Level-Steuerung.
Sie funktioniert jedoch nur mit Chromium-basierten Browsern und ist kein offener Standard. Außerdem sind CDP-APIs relativ komplex. In einigen Fällen ist die Arbeit mit CDP nicht ergonomisch. Die Arbeit mit Out-of-Process-Iframes ist beispielsweise sehr aufwendig.
Wenn Sie beispielsweise auf ein Element await coffee.click(); klicken, wird dies in eine Reihe von CDP-Befehlen übersetzt.
// 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 }
}
Was sind die Low-Level-Steuerungen?
Als WebDriver „Classic“ entwickelt wurde, war keine Low-Level-Steuerung erforderlich. Aber die Zeiten haben sich geändert, das Web ist jetzt viel leistungsfähiger und Tests erfordern heute detailliertere Aktionen.
Da CDP für alle Anforderungen beim Debuggen entwickelt wurde, unterstützt es im Vergleich zu WebDriver „Classic“ mehr Low-Level-Steuerelemente. Es kann folgende Funktionen verarbeiten:
- Konsolenmeldungen erfassen
- Netzwerkanfragen abfangen
- Gerätemodus simulieren
- Standortbestimmung simulieren
- …und vieles mehr
Aufgrund der unterschiedlichen Architektur waren diese in WebDriver „Classic“ nicht möglich. WebDriver „Classic“ ist HTTP-basiert, was das Abonnieren und Abhören von Browserereignissen erschwert. CDP hingegen ist WebSocket-basiert und unterstützt standardmäßig die bidirektionale Kommunikation.
Nächste Schritte: WebDriver BiDi
Hier eine Zusammenfassung der Stärken von WebDriver „Classic“ und CDP:
| WebDriver „Classic“ | Chrome DevTools Protocol (CDP) |
|---|---|
| Beste plattformübergreifende Unterstützung | Schnelle, bidirektionale Nachrichtenübermittlung |
| W3C-Standard | Bietet eine detaillierte Steuerung |
| Für Tests konzipiert |
WebDriver BiDi soll die besten Aspekte von WebDriver „Classic“ und CDP kombinieren. Es ist ein neues Standardprotokoll für die Browserautomatisierung, das derzeit in der Entwicklung ist.
Weitere Informationen zum WebDriver BiDi-Projekt – Funktionsweise, Vision und Standardisierungsprozess.