Antwort.

Historisch gesehen hatten Tester bei der Automatisierung von Tests komplexer Prozesse, die mehrere Komponenten (UI, API, Datenbanken, externe Dienste) umfassen, mit Schwierigkeiten zu kämpfen: Duplizierung von Logik, mangelnde Kohärenz der Tests und die Unmöglichkeit, ein durchgängiges Nutzungsszenario des Produkts zu reproduzieren.

Das Problem ist, dass solche Tests oft über die Grenzen eines Subsystems hinausgehen, komplexe Datenvorbereitungen, Umgebungsanforderungen und die richtige Reihenfolge von Interaktionen zwischen verschiedenen Teilen des Systems erfordern. All dies macht die Ausführung, Wiederholbarkeit und Wartung von automatisierten Tests erheblich komplizierter.

Die Lösung besteht darin, durchgängige Automatisierung (End-to-End-Automatisierung) einzusetzen und die Vorbereitung von Zuständen in separate Schichten zu verlagern, indem man Test-Helfer und hybride Ansätze verwendet (z. B. Datenvorbereitung über direkten Datenbankzugriff oder API und die Überprüfungen selbst über das UI). Dies ermöglicht es, die Komplexität unter Kontrolle zu halten, ohne die Tests mit überflüssiger Logik zu belasten. Ein solcher Ansatz lässt sich gut nach Mustern strukturieren.

Beispiel:

# Daten über die API vorbereiten
def create_order():
    ...
# Ergebnis über das UI überprüfen
def test_order_flow():
    id = create_order()
    go_to_order_page(id)
    assert get_status_from_ui() == 'COMPLETED'

Wesentliche Merkmale:

Mehrstufige Datenvorbereitung und -validierung.
Klare Trennung der Verantwortung jedes Tests (API, UI, Datenbank).
Verwendung von Mocks oder Stubs für externe Abhängigkeiten.

Fangfragen.

Kann man sich nur auf UI-Tests verlassen, um durchgängige Prozesse zu überprüfen?

Nur UI-Tests sind nicht zuverlässig genug, zu langsam und ermöglichen es oft nicht, komplexe Szenarien mit großen Datenmengen und unterschiedlichen Zuständen vollständig zu prüfen.

Wie geht man mit instabilen externen Diensten während der Durchführung von E2E-Tests um?

Verwenden Sie Mocks und Stub-Dateien, um die Auswirkungen von Ausfällen und der Nichtverfügbarkeit externer Dienste auf die Stabilität der E2E-Tests zu minimieren.

Müssen negative Fälle auf jeder Ebene komplexer Prozesse abgedeckt werden?

Ja, sonst könnten Integrationsfehler zwischen den Schichten übersehen werden.

Typische Fehler und Anti-Muster

„Fette“ Tests, die zu viel auf einmal ausführen.
Verwirrte Datenvorbereitung innerhalb des Tests (Verletzung des Prinzips der Verantwortungsaufspaltung).
Fehlende Isolation der Daten zwischen den Tests.

Beispiel aus dem Leben

Negativer Fall

In einem neuen Projekt begannen Tester, End-to-End-Tests zu erstellen, die die Aktionen des Benutzers über das UI vollständig emulierten, dachten jedoch nicht an die Datenvorbereitung und die Stabilität der Umgebung – die Tests fielen manchmal aus, wenn externe Dienste nicht verfügbar waren oder verändert wurden.

Vorteile:

Maximal nah am Nutzungsszenario des Benutzers.
Leicht dem Geschäft zu demonstrieren.

Nachteile:

Schwierigkeit der Wartung.
Sinkende Stabilität (Abhängigkeit von externen Diensten).
Schwierige Fehlersuche.

Positiver Fall

In einer ähnlichen Situation wurden die Tests in Datenvorbereitung (über API), Überprüfung der Geschäftslogik über das UI und Isolierung der externen Abhängigkeiten durch Mocks unterteilt. Dies erhöhte erheblich die Geschwindigkeit, Stabilität und Transparenz des Testens.