Testy end to end na dużą skalę, czyli jak unikać testowego spaghetti

W pewnym momencie każda większa organizacja dochodzi do tego samego miejsca. Automatyzacja działa, testy „end to end” rosną, coverage wygląda coraz lepiej, a mimo to wdrożenia dalej są stresujące. Pipeline jest dłuższy niż powinien. Czerwone buildy pojawiają się częściej, niż wynikałoby to z realnych defektów. A najgorsze jest to, że kiedy coś się psuje, nikt nie wie, czy to problem z produktem, testami, środowiskiem czy danymi. Wtedy testy „end to end” przestają być siecią bezpieczeństwa. Zaczynają być makaronem, w którym wszystko jest połączone ze wszystkim i każde dotknięcie kończy się lawiną.

To właśnie nazywam testowym spaghetti. Nie chodzi o liczbę testów. Chodzi o strukturę, zależności i to, czy testy dają sygnał, czy generują hałas.

Skąd bierze się testowe spaghetti

Najczęściej z dobrych intencji. Ktoś ma produkcyjny incydent, więc dopisuje test end to end, żeby to się nie powtórzyło. Ktoś inny chce podnieść coverage, więc automatyzuje kolejne scenariusze przez UI, bo to jest najbardziej namacalne. Ktoś trzeci dorzuca testy na tej samej ścieżce, tylko z inną kombinacją danych. Po roku masz setki testów, które teoretycznie bronią jakości, ale praktycznie robią trzy rzeczy: wydłużają feedback, zwiększają flakiness i utrudniają diagnozę.

Jest też drugi mechanizm. E2E stają się domyślnym narzędziem do testowania wszystkiego, bo inne poziomy testów są słabe albo nie istnieją. Brakuje testów kontraktowych, brakuje integracji na API, brakuje testów komponentów, więc UI przejmuje całą odpowiedzialność. A UI to najdroższe miejsce do testowania, bo jest wolne, kruche i zależne od wszystkiego.

Objawy, że wchodzisz w spaghetti

Jeśli widzisz te sygnały, to nie jest kwestia chwilowego kryzysu. To jest kwestia konstrukcji suity.

Pierwszy objaw to czerwone buildy, które coraz częściej kończą się zdaniem to flake. Jeśli zespół przestaje ufać czerwieni, to przestaje działać cały mechanizm kontroli jakości.

Drugi objaw to długi czas do diagnozy. Test pada, ale logi są nieczytelne, screenshot nic nie mówi, a odtworzenie problemu wymaga pół godziny zabawy. Wtedy test nie jest narzędziem feedbacku, tylko zadaniem detektywistycznym.

Trzeci objaw to testy, które są długie i obejmują zbyt wiele kroków. Logowanie, wyszukiwanie, dodanie do koszyka, checkout, płatność, mail, tracking. Gdy taki test padnie, nie wiesz, co tak naprawdę się zepsuło. A jeśli nie wiesz, to znaczy, że test jest zbyt gruby.

Czwarty objaw to zależność od wspólnego stanu. Testy używają tych samych kont, tych samych danych, tej samej puli zasobów. Jeden test zmienia stan, drugi na nim polega, trzeci sprząta, czwarty sprząta źle. To jest klasyczny przepis na nieprzewidywalność.

Piąty objaw to automatyzacja tego, co ciągle się zmienia. UI jest przebudowywane, copy się zmienia, layout żyje, a testy są oparte na kruchych selektorach i kolejności kliknięć. Utrzymanie zaczyna kosztować więcej niż wykrywane defekty.

Zasada, która ustawia wszystko na właściwe tory

Testy end to end są potrzebne, ale mają być cienką warstwą. Ich rola nie polega na tym, żeby sprawdzić wszystko. Ich rola polega na tym, żeby potwierdzić, że najważniejsze rzeczy działają w realnym przepływie i że integracja systemu się nie rozjechała.

Jeśli Twoje E2E próbują zastąpić testy jednostkowe, integracyjne i kontraktowe, to przegrasz. Nie dlatego, że E2E są złe. Dlatego, że są zbyt drogie, żeby robić wszystko.

Jak uniknąć spaghetti w praktyce

Odetnij suity od zależności i wspólnego stanu

Największy prezent, jaki możesz zrobić E2E, to deterministyczność. Każdy test powinien mieć własne dane, własne zasoby i własną ścieżkę sprzątania. Jeśli nie da się tego zrobić w pełni, to przynajmniej izoluj to, co jest krytyczne. Oddziel konta testowe. Oddziel koszyki. Oddziel zamówienia. Oddziel dane klienta. Jeśli dwa testy walczą o ten sam stan, to w długim terminie przegrywasz.

W praktyce oznacza to też inwestycję w API do przygotowania danych. UI nie powinno służyć do robienia setupu, bo setup przez UI jest wolny i kruchy. Setup rób API albo bezpośrednio na poziomie serwisów, a UI zostaw na to, co ma sprawdzić.

Krój testy na mniejsze, celowe scenariusze

Długi test, który sprawdza wszystko, jest kuszący, bo wygląda jak prawdziwa ścieżka użytkownika. Tylko że prawdziwa ścieżka użytkownika to nie jest najlepsza jednostka diagnostyczna.

Zamiast jednego testu od logowania do płatności, zrób kilka krótszych, które mają jasną odpowiedzialność. Jeden test sprawdza logowanie i sesję. Drugi sprawdza dodanie produktu do koszyka. Trzeci sprawdza przejście przez checkout do kroku wyboru metody płatności. Czwarty sprawdza integrację z bramką płatniczą, ale już z przygotowanym koszykiem. Dzięki temu, gdy coś padnie, wiesz, gdzie padło. A to jest różnica między sygnałem a chaosem.

Ustal kontrakty i przenieś większość pokrycia niżej

Najlepszy sposób na odchudzenie E2E bez utraty ochrony to przenoszenie ryzyk z UI na API, kontrakty i integracje. Wiele regresji, które dziś łapiesz przez klikane UI, możesz złapać szybciej i stabilniej na poziomie serwisów. Kontrakt API powie Ci, że zmieniło się pole. Test integracyjny powie Ci, że zmieniła się logika. A E2E będzie tylko potwierdzać, że całość spina się z perspektywy użytkownika.

To jest też sposób na skrócenie pipeline. Nie przez dokupienie runnerów, tylko przez zmianę struktury.

Przestań automatyzować wszystko, zacznij automatyzować ryzyko

Każdy test E2E powinien mieć metkę ryzyka. Dlaczego on istnieje. Co chroni. Jaki koszt miałby błąd w tym miejscu. Jeśli nie potrafisz tego powiedzieć w jednym zdaniu, test prawdopodobnie jest kandydatem do usunięcia albo przeniesienia niżej.

W dużych projektach suita rośnie, bo nikt nie usuwa testów. A prawda jest taka, że testy też mają cykl życia. Scenariusz, który był krytyczny dwa lata temu, dziś może być marginalny albo pokryty na innym poziomie. Bez regularnego odchudzania każda suita zamienia się w muzeum dawnych problemów.

Zrób porządek z selektorami i stabilnością UI

To nie jest temat sexy, ale robi różnicę. Kruchy selektor to kruchy test. Jeśli testy używają selektorów zależnych od layoutu, klasy CSS czy tekstu, to będą padać przy byle zmianie. Stabilne atrybuty testowe są nudne, ale oszczędzają miesiące frustracji. Do tego dochodzi jedna zasada, która ratuje życie. Nie testuj animacji. Nie testuj timingów. Testuj stany. Czekaj na warunki, nie na czas.

Naucz się traktować flakiness jak dług, nie jak irytację

Flakiness nie jest drobną usterką. To jest dług jakości w automatyzacji. Jeśli go nie spłacasz regularnie, przestajesz ufać wynikowi suity. A jeśli nie ufasz, to suita przestaje być bramką jakości.

W praktyce działa prosta rzecz. Lista najczęściej padających testów, właściciel i cotygodniowy limit czasu na naprawy. Nie raz na kwartał. Co tydzień. Zaczynasz od tych, które padają najczęściej i najdrożej, czyli blokują pipeline i wymagają triage.

Zrób dwa tryby uruchomień zamiast jednej wielkiej suity

Duże organizacje wygrywają tym, że nie próbują uruchamiać wszystkiego zawsze. Mają szybki zestaw, który leci na każdą zmianę i ma dać decyzję merge. I mają zestaw głębszy, który leci cyklicznie, nocą albo przed releasem, żeby wyłapać szersze ryzyka. Jeśli wszystko leci zawsze, pipeline staje się korkiem. Jeśli nic nie leci zawsze, pipeline staje się fikcją. Potrzebujesz dwóch prędkości.

Krótka checklista, która ratuje E2E przed spaghetti

Jeśli chcesz sprawdzić, czy idziesz w dobrą stronę, zadaj sobie kilka pytań.

• Czy większość testów jest niezależna i może lecieć w dowolnej kolejności?
• Czy czas uruchomienia suity jest akceptowalny, a najważniejszy feedback przychodzi szybko?
• Czy testy mają jasny cel i metkę ryzyka?
• Czy większość pokrycia jest niżej niż UI?
• Czy flakiness jest mierzony i redukowany, a nie tylko komentowany?

Jeśli na któreś z tych pytań odpowiedź brzmi nie, to nie jest porażka. To jest sygnał, gdzie jest największy zwrot z inwestycji w naprawę.

Podsumowanie

Testy „end to end” na dużą skalę są możliwe, ale tylko wtedy, gdy nie próbują być wszystkim. E2E mają być cienką warstwą potwierdzającą, że krytyczne rzeczy działają w realnym przepływie. Jeśli zrobisz z nich główne narzędzie testowania całego produktu, dostaniesz testowe spaghetti, powolny pipeline i zespół, który przestaje ufać automatyzacji. A wtedy wracasz do strachu przed wdrożeniem, tylko z większą liczbą testów.

Jeśli Twoje testy end to end zaczęły przypominać testowe spaghetti, w Quality Island pomagamy zespołom odzyskać kontrolę nad automatyzacją bez wywracania całego procesu. Robimy przegląd suity E2E pod kątem wartości i ryzyka, wycinamy testy, które generują hałas, porządkujemy dane testowe i niezależność scenariuszy, a ciężar pokrycia przenosimy z UI na API. Kontrakty i integracje przenosimy tam, gdzie daje to największy zwrot. Kończymy z krótszym pipeline, mniejszym flakiness i zestawem E2E, który naprawdę daje pewność przed wdrożeniem. Jeśli chcesz, żeby automatyzacja znowu była dźwignią, a nie problemem, odezwij się do nas.