Zum Inhalt

Einstieg in End-To-End Tests (E2E Tests)

End-To-End Tests (E2E Tests) sind eine wichtige Komponente der Softwareentwicklung, die sicherstellen, dass eine Anwendung als Ganzes funktioniert.
E2E-Tests sind automatisierte Tests, die den gesamten Ablauf einer Anwendung von Anfang bis Ende testen.
Im Prinzip genauso, wie wenn ein realer Benutzer mit dem System interagiert.

E2E Test Sie testen typischerweise:

  • Benutzeroberfläche (UI)
  • Backend-Services
  • Datenbankzugriffe
  • Schnittstellen (APIs)
  • Browser-/Client-Interaktionen

Abgrenzung zu anderen Testarten

Testart Fokus Beispiel
Unit-Tests Einzelne Funktion/Komponente Prüft: add(2,3) → 5
Integrationstests Zusammenspiel mehrerer Komponenten Prüft: API ⇄ Datenbank
Systemtests Gesamtes System ohne Benutzerinteraktion Prüft: Backend-Endpunkte funktionieren systemweit
E2E-Tests Simuliert reale Benutzerabläufe Prüft: Nutzer loggt sich ein, sucht ein Produkt, bestellt es

Kurz:
- Unit: Funktion/Komponente
- Integration: Zusammenspiel mehrerer Komponenten - System: gesamtes System
- E2E: kompletter Benutzerflow über UI

Beispiele für zwei typische E2E-Tests

Beispiel 1: Login

  1. Seite öffnen
  2. Benutzername eingeben
  3. Passwort eingeben
  4. Login klicken
  5. Prüfen, ob Dashboard sichtbar wird

Beispiel 2: Produkt bestellen

  1. Produktseite öffnen
  2. Produkt in den Warenkorb legen
  3. Zum Checkout gehen
  4. Bestellung abschliessen
  5. Prüfen ob Bestellbestätigung sichtbar wird

Konzepte von E2E-Tests

Es gibt verschiedene Ansätze und Tools für die Implementierung von E2E-Tests.
Diese lassen sich grob in drei Kategorien einteilen:

WebDriver-basiert

WebDriver ist ein Standard (W3C), der beschreibt, wie ein Testprogramm mit einem Browser kommuniziert. Dabei wird das WebDriver-Protokoll verwendet, um Befehle an den Browser zu senden und Ergebnisse zurückzuerhalten.
Ein WebDriver-basiertes Tool sendet Befehle wie:

  • "Öffne URL"
  • "Klicke auf Button"
  • "Gib Text ein"
  • "Lies Element aus"

Und erhält Antworten wie:

  • "Element gefunden"
  • "Textwert ist 'Hallo Welt'"
  • "Seite geladen"

Beispiele von WebDriver-basierten Tools:

  • Selenium
  • WebdriverIO
  • Appium

Vorteile:

  • Unterstützt alle üblichen Browser
  • Realitätsnahe Simulation von Benutzerinteraktionen

Nachteile:

  • Eher eine ältere Architektur
  • Etwas langsamer, da Befehle über das WebDriver-Protokoll gesendet werden
  • Die Tests sind manchmal unzuverlässig. Sie schlagen zBsp. fehl, obwohl der Code korrekt ist und nichts geändert wurde.

DevTools-/Engine-basiert (CDP)

Nutzt Debugging-Schnittstellen des Browsers wie das Chrome DevTools Protocol (CDP).
Das Chrome DevTools Protocol (CDP) ist eine interne Schnittstelle, über die Chrome (und Chromium-basierte Browser wie Edge) von aussen gesteuert, überwacht und debuggt werden können.
Diese Schnittstelle wird zBsp. auch von den Chrome Developer Tools selbst genutzt.

Über CDP kann man Dinge tun wie:

  • einen Button klicken lassen
  • JavaScript im Browser ausführen
  • Screenshots machen
  • Netzwerk-Anfragen abfangen
  • Performance messen
  • Browser-Konsole auslesen
  • Cookies setzen / löschen
  • DOM-Struktur verändern

Das Ergebenis kann via CPD geprüft werden, via:

  • DOM
  • Events
  • Netzwerk
  • Status der Browser-Engine

Beispiele für CDP-basierte Tools:

  • Puppeteer
  • Playwright

Vorteile:

  • Moderne Architektur
  • Schnell, stabil
  • Prüft direkt im Browser
  • Weiss automatisch, wann DOM stabil ist
  • Kann Request/Response live beobachten
  • Netzwerk-Mocking, Request-Interception

Nachteile:

  • CDP primär für Chrome optimiert
    (Playwright löst das teils)

In-Browser-Ansatz (DOM-basiert)

Beim In-Browser-Ansatz läuft der Test nicht ausserhalb des Browsers (wie bei WebDriver oder CDP), sondern im Browser selbst, im Kontext der getesteten Webanwendung. Der Testcode wird also direkt im Browser ausgeführt und hat vollen Zugriff auf das DOM, die JavaScript-Umgebung und die Netzwerkaktivitäten der Anwendung.
Der Testcode kann so direkt mit der Anwendung interagieren, Elemente manipulieren, Events auslösen und den Zustand der Anwendung überprüfen.

Der Test kann:

  • das gleiche JavaScript-Event-System nutzen
  • den gleichen DOM-Baum lesen
  • die gleichen XHR-/Fetch-Requests sehen
  • dieselben Browser-APIs verwenden
  • auf die Anwendung reagieren, ohne extern zu warten

Beispiel: Wenn ein Button erscheint, sieht Cypress das sofort, weil derselbe DOM genutzt wird.
Das macht diese Tools extrem stabil.

Beispiel für In-Browser-Test-Tools:

  • Cypress
  • TestCafe

Anwendungsbeispiel mit Cypress:

Man schreibt einen Test, der eine Login-Seite öffnet, Benutzerdaten eingibt und auf den Login-Button klickt:

cy.visit("https://meineapp.com/login");
cy.get("#username").type("meinBenutzer");
cy.get("#password").type("meinPasswort");   

cy.get("#login").click();
cy.get("#dashboard").should("be.visible");

Es passiert folgendes:

  • Cypress führt JavaScript im Browser aus
  • Direkter Zugriff auf den DOM von document
  • Echter Klick im selben Event-Loop wie die App
  • Framegenaue Prüfung der DOM-Änderungen

Vorteile:

  • Direkter DOM-Zugriff: Keine Verzögerung oder Synchronisationsprobleme
  • Automatische Waits: Wartet intern, bis Elemente bereit sind
  • Stabil und schnell: Weniger moving parts als WebDriver
  • Netzwerk-Interception: Kann Requests abfangen und mocken
  • Debugging sehr einfach: Test und App im gleichen Fenster sichtbar

Nachteile:

  • Keine echten Multi-Browser-Tests: Cypress unterstützt Chrome/Edge/Firefox, aber WebKit/Safari nur eingeschränkt
  • Eingeschränkte Multi-Tab-Funktionalität: Eine Browser-Tab-Simulation ist schwierig, weil Cypress im Kontext eines Tabs läuft
  • Nicht für alle Architekturen geeignet: zBps sehr strikte Security-Policies (CSP) könnten einschränken