Antwort.

Geschichte der Frage:

Ursprünglich wurden automatisierte Tests oft "aus dem Stegreif" geschrieben, ohne architektonische Trennungen: Prüf-Logik und Ausführungsmechanismen wurden vermischt. Mit dem Wachstum von Projekten wurde offensichtlich, dass die Vermischung von Framework- und Testlogik eine fragile, schwer wartbare Codebasis schafft. Es entstanden architektonische Empfehlungen zur Trennung der Verantwortung.

Problem:

Wenn Tests von internen Implementierungen des Frameworks abhängen oder Logik zur Interaktion mit der Umgebung enthalten, zwingt jede Änderung dazu, viele Tests neu zu schreiben. Testfälle sind komplex, Code wird dupliziert, die Migration auf ein neues Framework oder eine neue Plattform wird erschwert.

Lösung:

Strikte Trennung:

Framework (Basisinfrastruktur): allgemeine Mechanik zum Starten von Tests, Protokollierung, Fehlerverarbeitung, Berichte, Basis für Hilfsklassen (z. B. Treiber, Adapter und Dienstprogramme).
Testlogik (Testfälle): konkrete Szenarien, die den sinnlichen Zweck des Tests ausdrücken, verwenden nur öffentliche API des Frameworks.

Wichtige Merkmale:

Einfache Wartung durch Isolierung plattformübergreifender Änderungen
Möglichkeit, Testlogik wiederzuverwenden
Reduzierung von Redundanz und Code-Duplizierung

Fangfragen.

Kann man Testschritte direkt in den Tests schreiben, wenn es sehr wenige sind?

Sollte man nicht. Selbst kurze Tests können wachsen, und das Fehlen von Schichten führt schnell zu Chaos.

Sollten Testszenarien über die Startmechanik Bescheid wissen (z. B. wann Treiber initialisiert werden sollten)?

Nein. Alle Details der Infrastruktur sollten im Framework-Schicht verborgen bleiben.

Ist es normal, Testparameter innerhalb von Fällen hart zu codieren (z. B. URL, Anmeldeinformationen)?

Nein. Testparameter sollten über die Einstellungen des Frameworks und der Umgebung konfiguriert werden.

Typische Fehler und Anti-Patterns

Überprüfung des Zustands innerhalb der Methoden des Frameworks, nicht der Tests
Verwendung privater Methoden des Frameworks in Tests
Duplizierung von Hilfsfunktionen in Tests
Hartcodierung von Parametern

Beispiel aus dem Leben

Negativer Fall

Im Projekt rufen Tests direkt Methoden des Selenium-Treibers auf, in jedem Test wird die Verbindung zu WebDriver wiederholt. Jeder Test parst selbstständig die Konfiguration.

Vorteile:

Man kann schnell beginnen, automatisierte Tests ohne Architektur zu schreiben

Nachteile:

Änderungen am Treiber oder an den Startparameter führen zu massiven Anpassungen
Duplicated Code in allen Tests
Schwer zu skalieren und zu warten

Positiver Fall

Tests verwenden grundlegende Abstraktionen des Frameworks: allgemeine Initialisierung und Teardown, Durchreiche von Parametern über den Konfigurator, Testlogik wird durch hochgradige Methoden ausgedrückt.