© faithie/Shutterstock.com, © S&S Media
Windows Developer
Teil 2: Remote Browser-Testing mittels WebSockets einfach umsetzen

Mit WebSockets den Browser fernsteuern

Die Fähigkeiten eines Browsers zu nutzen, auch wenn die eigentliche Applikation gar nicht im Browser läuft - wie kann das gehen? Mittels WebSockets und ein wenig JavaScript lässt sich das im Prinzip einfach umsetzen.

Thomas Mahringer


Quellcode zum Download

ArtikelserieTeil 1: Die Browserkonsole als remote Logausgabe verwendenTeil 2: Remote Browser-Testing mittels WebSockets einfach umsetzen

Im ersten Teil haben wir zwei Anwendungsfälle für die remote Ausführung von Browserfunktionalität betrachtet: Die Verwendung des Browsers als remote Logging Console und die Automatisierung von Browsertests. Letzteren Anwendungsfall haben wir bisher nur theoretisch beschrieben und wollen ihn jetzt komplett umsetzen.

Die Grundidee

Der Anwendungsfall der remote Browserkonsole war relativ einfach: Eine serverseitige Anwendung sendet dem Browser über WebSockets Logkommandos nach dem Prinzip „Fire and Forget“. Der Browser hat die Kommandos hoffentlich ausgeführt, aber leider noch keine Rückmeldung dazu gegeben. Jetzt geht es darum, eine Browserapplikation remote zu testen. Dazu ist es notwendig, dass wir nicht nur Kommandos absetzen, sondern auch Ergebnisse zurückbekommen, z. B. die Testresultate. Um das Beispiel auch in seiner Gesamtheit gut erläutern zu können, verwenden wir eine React-Applikation und die zugehörigen Tests. Die Applikation und die Tests sind im Vergleich zu einer Echtapplikation stark vereinfacht, da sie das dahinterliegende Prinzip zeigen sollen.

UI-Integrationstests

Was und wie genau wollen wir testen? Wir haben letztes Mal bereits den Mehrwert von UI-Integrationstests aus DevOps-Sicht hervorgehoben: Wir testen im Sinne von White- oder Grey-Box-Tests komplette Use Cases der Applikation durch. Im Gegensatz zu simulierten UI-Tests (z. B. mit Selenium) haben wir Zugriff auf die interne Applikationsstruktur. Dabei gehen wir aber nicht auf Implementierungsdetails wie bei Unit-Tests ein, sondern auf High-Level-Objekte wie z. B. die UI-Komponenten. In Abbildung 1 sehen wir ein konkretes, wenn auch stark vereinfachtes Beispiel: Unsere Applikation verwendet zwei UI-Komponenten (PersonList und ProjectList). Die Testmethoden haben vollen Zugriff auf die Komponenten, so wird z. B. in Listing 1 über den Router zur PersonList navigiert und deren „State“ abgeprüft. Vom Entwicklungszyklus her sieht es so aus, dass die Testmethoden testPersonList und testProjectList gemeinsam mit der App entwickelt werden. Die benötigten Abhängigkeiten werden auf Sourcecode-Ebene importiert und die Tests mit diesen Abhängigkeiten kompiliert (TypeScript, in Listing 2 sieht man die komplette Testsuite und ihre Importe.) Ein großer Vorteil liegt darin, dass im Fall von Refaktorisierungen die Tests auch mitfa...

Windows Developer
Teil 2: Remote Browser-Testing mittels WebSockets einfach umsetzen

Mit WebSockets den Browser fernsteuern

Die Fähigkeiten eines Browsers zu nutzen, auch wenn die eigentliche Applikation gar nicht im Browser läuft - wie kann das gehen? Mittels WebSockets und ein wenig JavaScript lässt sich das im Prinzip einfach umsetzen.

Thomas Mahringer


Quellcode zum Download

ArtikelserieTeil 1: Die Browserkonsole als remote Logausgabe verwendenTeil 2: Remote Browser-Testing mittels WebSockets einfach umsetzen

Im ersten Teil haben wir zwei Anwendungsfälle für die remote Ausführung von Browserfunktionalität betrachtet: Die Verwendung des Browsers als remote Logging Console und die Automatisierung von Browsertests. Letzteren Anwendungsfall haben wir bisher nur theoretisch beschrieben und wollen ihn jetzt komplett umsetzen.

Die Grundidee

Der Anwendungsfall der remote Browserkonsole war relativ einfach: Eine serverseitige Anwendung sendet dem Browser über WebSockets Logkommandos nach dem Prinzip „Fire and Forget“. Der Browser hat die Kommandos hoffentlich ausgeführt, aber leider noch keine Rückmeldung dazu gegeben. Jetzt geht es darum, eine Browserapplikation remote zu testen. Dazu ist es notwendig, dass wir nicht nur Kommandos absetzen, sondern auch Ergebnisse zurückbekommen, z. B. die Testresultate. Um das Beispiel auch in seiner Gesamtheit gut erläutern zu können, verwenden wir eine React-Applikation und die zugehörigen Tests. Die Applikation und die Tests sind im Vergleich zu einer Echtapplikation stark vereinfacht, da sie das dahinterliegende Prinzip zeigen sollen.

UI-Integrationstests

Was und wie genau wollen wir testen? Wir haben letztes Mal bereits den Mehrwert von UI-Integrationstests aus DevOps-Sicht hervorgehoben: Wir testen im Sinne von White- oder Grey-Box-Tests komplette Use Cases der Applikation durch. Im Gegensatz zu simulierten UI-Tests (z. B. mit Selenium) haben wir Zugriff auf die interne Applikationsstruktur. Dabei gehen wir aber nicht auf Implementierungsdetails wie bei Unit-Tests ein, sondern auf High-Level-Objekte wie z. B. die UI-Komponenten. In Abbildung 1 sehen wir ein konkretes, wenn auch stark vereinfachtes Beispiel: Unsere Applikation verwendet zwei UI-Komponenten (PersonList und ProjectList). Die Testmethoden haben vollen Zugriff auf die Komponenten, so wird z. B. in Listing 1 über den Router zur PersonList navigiert und deren „State“ abgeprüft. Vom Entwicklungszyklus her sieht es so aus, dass die Testmethoden testPersonList und testProjectList gemeinsam mit der App entwickelt werden. Die benötigten Abhängigkeiten werden auf Sourcecode-Ebene importiert und die Tests mit diesen Abhängigkeiten kompiliert (TypeScript, in Listing 2 sieht man die komplette Testsuite und ihre Importe.) Ein großer Vorteil liegt darin, dass im Fall von Refaktorisierungen die Tests auch mitfa...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang