Automatisiertes UI-Testing für eine Content-Website

Im Rahmen meiner Arbeit habe ich eine Testautomatisierung für meine eigens entwickelte Website „Astrid Lindgren“ erstellt. Ziel ist es, anschaulich zu zeigen, wie moderne UI-Tests mit WebdriverIO und dem JSON Reporter zuverlässig die Funktionsfähigkeit einer Webseite prüfen können.

Die Tests rufen automatisiert die Seite auf, überprüfen relevante Seitenelemente und Funktionen – etwa Überschriften, Links oder dynamischen Inhalte. Mit der Lösung kann sich sichergestellt werden, dass wichtige Bereiche einer Website auch bei Änderungen im Code oder Design stabil und funktional bleiben. Die Umsetzung mit dem WebdriverIO eignet sich gut für kleine Projekte, könnte aber auch als Einstieg in professionelle End-to-End-Tests für größere Webanwendungen eingesetzt werden.

Ziel des Projekts

Ziel des Projekts war es, typische Funktionen einer Website automatisiert zu testen. Ich habe hierfür mal wieder eines meiner alten Coding-Projekte verwendet, ein kleiner Einblick:

Nachdem ich mir von ChatGPT zunächst verschiedene Testideen vorschlagen gelassen hatte, habe ich mir daraus gezielt einige passende Szenarien ausgewählt. Die Ergebnisse der Tests lasse ich dabei automatisch in einem JSON-Reporter dokumentieren.

ChatGPT schlägt folgende Tests vor – die grün markierten habe ich schließlich für mein Projekt ausgewählt.

Ich prüfe in diesem Projekt also, wie man:

die Darstellung auf mobilen Geräten prüft,
ein Burger-Menü testet,
fehlerhafte Links erkennt,
das Vorhandensein von Logo und Bildern testet,
Überschriften und Inhalte, genauer gesagt eine Leseprobe zu Astrid Lindgren checkt
einen Slider auf Funktionsfähigkeit prüft

Eingesetzte Technologien

WebdriverIO (v9.1.2)
JavaScript, Mocha, Chai
JSON Reporter (für JSON-Testberichte)
Axios (zur Überprüfung von Links)

Installation und Aufsetzen des Projektes

Für die Installation des Projektes setzte ich wie angekündigt auf WebdriverIO. Nach der Initialisierung des Projekts habe ich also den WDIO Configuration Wizard gestartet, um die wdio.conf.js-Datei zu erstellen. Dabei wählt man das gewünschte Testframework, den Browser und zusätzliche Services aus, wie den Selenium Standalone Service und den gewünschten Reporter. Nachfolgend ein kleiner Einblick:

Nach dem Setup habe ich in der Konfigurationsdatei noch die specs auf den Ordner für die Testdateien gesetzt.

Sobald diese Änderungen vorgenommen wurden, war das Projekt startklar. Also, worauf warten wir noch? 🙂

Der erste Test: lindgren-menue-footer.js

Der erste Test, lindgren-menue-footer.js, prüft in der Testsuite describe("Website Lindgren: Menüpunkte und Footer sichtbar"), ob alle Menüpunkte und Footer-Links auf der Website „Lindgren“ korrekt angezeigt werden. Zunächst wird die Seite geladen, gefolgt von einer Überprüfung, ob jeder Menüpunkt und Footer-Link sichtbar ist. Dabei wird XPath verwendet, um die Links präzise auszuwählen, und die Methode toBeDisplayed stellt sicher, dass die Elemente tatsächlich auf der Seite sichtbar sind.

So ging’s weiter:

Nachdem ich die oben genannten Tests allesamt ausgearbeitet hatte, nahm das kleine Projekt eine klare Struktur an:

├── reports
│ └── json-results (*)
│ ├── wdio-0-0-json-reporter.log
│ ├── wdio-0-1-json-reporter.log
│ ├── wdio-0-2-json-reporter.log
│ ├── wdio-0-3-json-reporter.log
│ ├── wdio-0-4-json-reporter.log
│ └── wdio-0-5-json-reporter.log
├── test
│ └── specs
│ ├── lindgren-broken-links.js
│ ├── lindgren-images.js
│ ├── lindgren-menue-footer.js
│ ├── lindgren-reading-sample.js
│ ├── lindgren-responsive.js
│ └── lindgren-slider.js
└── wdio.conf.js

(*) Wie hier erkennbar, habe ich unter dem Verzeichnis reports/json-results die Ergebnisse der Tests im JSON-Format abgelegt. Diese Berichte sind besonders nützlich, um eine detaillierte Analyse der Testläufe durchzuführen und die Testergebnisse auf einfache Weise zu überprüfen.

Jeder Testlauf wird in einer eigenen Logdatei wie wdio-0-0-json-reporter.log bis wdio-0-5-json-reporter.log gespeichert. Diese Dateien bieten eine detaillierte Übersicht über alle Testaktivitäten und erleichtern die Fehleranalyse.

Die im obigen Bild erkennbaren JSON-Daten stammen aus einem Testbericht für die Suite „Broken Link Detection“. Der gesamte Testlauf dauerte 582 Millisekunden und wurde erfolgreich abgeschlossen, es gibt also keine ungültigen Links auf meiner Website. Ich habe zum Testen der Links übrigens die Bibliothek Axios genutzt. Es eignet sich hervorragend, um automatisiert viele URLs anzufragen und den HTTP-Statuscode auszuwerten.

Warum ich diesmal nicht mein geliebtes Allure verwende: Der JSON-Reporter bietet mir mehr Flexibilität, da er in einem maschinenlesbaren Format vorliegt, das einfach in andere Systeme integriert werden kann. Denn ich plane demnächst, die Jira-API zu nutzen, um fehlerhafte Tests automatisch als Tickets zu erstellen und so den Fehlerbehebungsprozess zu automatisieren. Falls ich hiermit weitergekommen bin, gebe ich ein Update.

Zum Abschluss: npx wdio run wdio.conf.js

Jetzt will ich aber endlich alle automatisierten Tests basierend auf den Einstellungen meiner wdio.conf.js ausführen.

Siehe da: Alle Tests durchgelaufen, alles grün – so darf das gerne aussehen! Die Lindgren-Website hat sich in allen Bereichen von guter Seite gezeigt: Bilder werden korrekt geladen, keine toten Links gefunden, das Burger-Menü klappt auf mobilen Geräten brav auf, und auch der Slider macht, was er soll.