Odpowiedź.

Historycznie, wraz ze zwiększeniem liczby automatycznych testów w projektach pojawiły się problemy: testy się myliły, przekraczały limity czasu wykonania, trudno było zrozumieć, co za co odpowiada. Co więcej, rosło ryzyko powstawania zależności między różnymi częściami systemu testowego i spowolnienia ogólnej pracy potoków.

Problem pojawia się, gdy liczba testów rośnie szybciej niż zapewniana jest architektoniczna pomoc w infrastrukturze testowej. Bez skalowalnych rozwiązań testy stają się wolne, trudne w utrzymaniu, utrudnia się wyszukiwanie i lokalizacja defektów, a także szybko rośnie dług technologiczny.

Rozwiązanie polega na wdrożeniu specjalnych strategii:

Klasteryzacja testów według modułów i poziomów (jednostkowe, integracyjne, E2E) z użyciem odpowiednich tagów i filtrów.
Równoległe uruchamianie testów (sharding, rozproszone zestawy testowe) w celu przyspieszenia wykonania.
Zastosowanie podejścia mikroserwisowego w infrastrukturze testowania: standardowe abstrakcje DSL, oddzielne usługi do zarządzania infrastrukturą testową.
Automatyzacja wykrywania powtarzających się i przestarzałych testów, regularny refaktoryzacja i audyt pokrycia.

Kluczowe cechy:

Modułowość i możliwość ponownego użycia testów i bibliotek testowych.
Pełna automatyzacja integracji CI/CD i możliwość autoskalowania zasobów.
Wdrożenie narzędzi monitorowania jakości automatycznych testów i pokrycia kodu.

Pytania z podwórka.

Czy można zrobić wszystkie testy tylko integracyjne, aby pokryć więcej kodu od razu?

Nie, takie podejście zmniejsza lokalizację defektów i prowadzi do wysokich kosztów utrzymania, a także do spowolnienia wykonania regresji.

Czy skalowalność automatycznych testów oznacza tylko ich przyspieszenie?

Skalowalność to zarówno architektura, jak i utrzymywalność, przyspieszenie oraz elastyczna infrastruktura. Przyspieszenie jest tylko konsekwencją dobrze zaprojektowanego dużego systemu.

Jak prawidłowo skalować testy dla zespołów pracujących w różnych strefach czasowych?

Wa żne jest przewidzenie możliwości lokalnego uruchamiania i niezależności środowisk testowych, w przeciwnym razie będą „konflikty” między zadaniami zespołów.

Typowe błędy i antywzorce

Wszystkie testy są pisane w jednym katalogu bez strukturyzacji według obszarów.
Ponowne użycie danych testowych bezpośrednio („copy-paste” zamiast bibliotek/fixture).
Brak monitorowania/metryk dotyczących czasu wykonania i stabilności testów.

Przykład z życia

Negatywny przypadek

W firmie pojawiło się od razu kilka zespołów, które dodawały nowe automatyczne testy do jednego folderu, nie uzgadniając swoich zmian. Po kilku tygodniach automatyczne testy zaczęły zawodzić z powodu niespójności danych i zależności, czas uruchamiania przekroczył 2 godziny.

Zalety:

Niski próg wejścia dla początkujących.
Szybki start automatyzacji.

Wady:

Brak skalowalności.
Trudność w wyszukiwaniu i analizie błędów.
Spowolnienie wydania produktów.

Pozytywny przypadek

W jednym z zespołów stworzono modułową strukturę, wprowadzono oddzielne CI dla obszarów kodu, zwiększono stabilność, wdrożono automatyczne alerty o nieefektywnych testach.