Odpowiedź.

Historia pytania:

Początkowo automatyczne testy często były pisane "na żywca", bez podziałów architektonicznych: logika weryfikacji i mechanizmy wykonania były wymieszane. Wraz z rozwojem projektów stało się oczywiste, że mieszanie frameworku i logiki testowej tworzy kruchą, trudną do utrzymania bazę kodu. Pojawiły się zalecenia architektoniczne dotyczące podziału odpowiedzialności.

Problem:

Jeśli testy zależą od wewnętrznych realizacji frameworku lub zawierają logikę interakcji z otoczeniem, wszelkie zmiany wymuszają przepisanie wielu testów. Przypadki testowe są skomplikowane, kod jest duplikowany, migracja do nowego frameworku lub platformy jest utrudniona.

Rozwiązanie:

Rygorystycznie rozdzielać:

Framework (podstawa infrastruktury): ogólna mechanika uruchamiania testów, logowanie, obsługa błędów, raporty, baza dla klas pomocniczych (np. sterowniki, adaptery i narzędzia).
Logika testowa (przypadki testowe): konkretne scenariusze, które wyrażają sensowny cel testu, używają tylko publicznych API frameworku.

Kluczowe cechy:

Łatwość w utrzymaniu dzięki izolacji zmian platformowych
Możliwość ponownego użycia logiki testowej
Zmniejszenie nadmiarowości i duplikacji kodu

Pytania z pułapką.

Czy można pisać kroki testowe bezpośrednio w testach, jeśli jest ich bardzo mało?

Nie warto. Nawet krótkie testy mogą się rozrosnąć, a brak warstw szybko prowadzi do chaosu.

Czy scenariusze testowe powinny znać mechanikę uruchamiania (np. kiedy inicjalizować sterownik)?

Nie. Wszystkie szczegóły infrastruktury powinny być ukryte w warstwie frameworku.

Czy normalne jest hardcodowanie parametrów testów wewnątrz przypadków (np. url, poświadczenia)?

Nie. Parametry testów powinny być konfigurowane przez ustawienia frameworku i otoczenia.

Typowe błędy i antywzorce

Umieszczanie sprawdzeń stanu wewnątrz metod frameworku, a nie testów
Używanie prywatnych metod frameworku w testach
Duplikowanie funkcji pomocniczych w testach
Hardcodowanie parametrów

Przykład z życia

Negatywny przypadek

W projekcie testy bezpośrednio wywołują metody sterownika Selenium, w każdym teście powtarza się połączenie z WebDriverem. Każdy test samodzielnie parsuje konfigurację.

Zalety:

Można szybko zacząć pisać testy automatyczne bez architektury

Wady:

Zmiana sterownika lub parametrów uruchamiania prowadzi do masowych poprawek
Zduplikowany kod we wszystkich testach
Trudno skalować i utrzymywać projekt

Pozytywny przypadek

Testy wykorzystują podstawowe abstrakcje frameworku: wspólna inicjalizacja i teardown, przesyłanie parametrów przez konfigurator, logika testowa wyrażana przez wysokopoziomowe metody.