Testy End-to-End - czy warto?

Ostatnio odszedł od nas gość, który na pełen etat zajmował się tworzeniem testów z wykorzystaniem Selenium (+ Java), w związku z czym pomagam czasem w utrzymywaniu tego cuda. Cały zestaw testów leci codziennie rano i wypluwa z siebie piękny raport z Cucumbera. Moje, oraz sporej części zespołu, spostrzeżenia są póki co takie:

• stworzenie scenariusza testowego trwa długo (webclient musi się przeklikać przez te wszystkie logowania, punkty menu itd., więc każda powtórka trwa)
• jeśli w raporcie wychodzą błędy, to ich analiza jest na ogół czasochłonna (a najczęściej błędy dotyczą samych scenariuszy, a nie systemu)
• co za tym idzie - utrzymanie testów end-to-end w jako-takim stanie i aktualności kosztuje bardzo dużo wysiłku
• trudno oprzeć się wrażeniu, że to narzędzie nie pomogło nam do tej pory (ok. 3 lata) wykryć żadnych poważniejszych błędów

Z jednej strony idea tego rodzaju testów wydaje się być przekonująca, szczególnie w przypadku mikroserwisów. Z drugiej strony manualni testerzy dużo sprawniej i szczegółowiej wyłapują różnego rodzaju bugi, natomiast serwisy zawierające porządne testy jednostkowe i integracyjne na ogół bronią się potem dość dobrze. Ponadto, gdy przypominam sobie wszystkie sytuacje typu

• oh nein! dlaczego ten test jest na czerwono? aa, znowu ktoś się zalogował jako testowy user i zmienił domyślny język, lub
• oh nein! aa, tekst w toast message ma na końcu kropkę, względnie
• oh nein! aa, zmienił się selektor css dla kwoty dodatniej,

to dostaję palpitacji serca w tej sekundzie.

Co sądzicie o testach end-to-end? Czy warto inwestować w to czas/energię/pieniądze?

Ja to się dziwię jak można w ogóle o coś takiego pytać.
Ale może pracuję ze specyficzną aplikacją (dużo konfiguracji, mało kodu).

Zmiany w css-ach nie powstają codziennie.
Natomiast błędy integracji kodu - tak, jak najbardziej mogą. Zwłaszcza jak łączysz pliki konfiguracyjne z iluś źródeł.
Ręczne testowanie kodu jest dobre, jak oddajesz pierwszy raz jakąś funkcjonalność.
Ale nie zatrudnisz stada ludzi, żeby Ci codziennie przeklikiwali aplikację, bo w końcu się wypalą.

O bardzo dobre.
Jestem odpowiedzialny za wyj...nie testów selenium w jednej dużej firmie, w kluczowym projekcie.
Selenium generowało bardzo dużo pracy (dla zespółu), dawało marne efekty. Uznałem, że mamy większe problemy i czas skoncentrować wysiłki gdzie indziej - więcej dobrych unit testów, lepsze buildy, kod, sonar itp.
Opór był duży, bo te testy selenium dużo pracy zespół kosztowały i szkoda troche było wyrzucać, ale efekt jest taki, że po wywaleniu było jakbyśmy wypłynęli na powierzchnię spod wody, nagle 25 % czasu więcej się zrobiło (tyle mniej więcej wysiłku szło w utrzymanie).

Tak dokładnie to zostawiiliśmy kilka testów, które miały charakter smoke - logowanie do aplikacji, sprawdzanie czy głowny ekran się załadował.

A teraz do rzeczy: to zależy.
Testy selenium mają sens przy pewnej skali: dużo przeglądarek do obsługiwania, dużo konfiguracji, bardzo dużo użytkowników (setki tysięcy), skomplikowana i krytyczna dla funkcjonalność dla biznesu klientów itd, trudny deployment (bo np. klient ma własne lokalne instalki).

Generalnie trzeba oszacować jak dużo kosztuje nas błąd (a w zasadzie jak dużo kosztuje nasz biznes).

Jira, github to projekty takie, że jak rypnie gui, przez głupi skrypt to następnego dnia wręcz miliony ludzi są dotknięte - tam takie testy mają sens. Wyobraźmy sobie, że wpada nowa wersja jiry nie przetestowana dobrze na IE 10 i pól , który akurat masz w banku i robi się dramat. To grozi utratą ważnego klienta.

Dla odmiany, typowa aplikacja wewnętrzna, gdzie użytkowników mamy w naszej firmie( i jest ich mniej niż 1000 ) zwykle nie uzasadnia inwestycji w selenium.
Sklep internetowy czy tego typu aplikacja, której funkcjonalność jest w stanie szybko przetestować dwóch wynajętych ziemian, również inwestycji w testy e2e zwykle nie uzasadnia.

Trzeba to wszystko rozważyć i oszacować ryzyko dla projektu - moim zdaniem w ponad 90% projektów są sensowniejsze rzeczy do zrobienia niż utrzymywanie selenium. Jest to zwykle dużo droższe niż się wydaje, szczególnie w utrzymaniu, nawet jak się page object stosuje.

Każdy test to jakieś tam betonowanie implementacji.
Jak zrobisz za dużo unit testów z mockowaniem to też będzie źle - w projekcie będzie duży koszt zmian.
Jak zrobisz za dużo smoke testów to z kolei oprócz CSS-a masz jeszcze problem wydajności tych testów. Zwykle są najwolniejsze i feedback przy wielu tych testach (>100) może być albo bardzo opóźniony (mieliśmy >4h) albo kosztowny (jeśli używasz więcej niż 1 joba na testy).
Myślę że bez przetestowania kluczowych ścieżek end2end (nie tylko happy) zawsze masz ryzyko że coś pójdzie nie tak. I to ryzyko najgrubszego gatunku (typu jenkins zielony, więc releasujesz, użytkownik nie może w ogóle wejść do danej funkcji).

Tutaj trochę n.t.
https://www.altkomakademia.pl/baza-wiedzy/qna/discussion/1020/smoke-testy-czym-sa/p1

1. Warto
2. Ale niekoniecznie z poziomu frontendu i selenium. Przecież możesz zrobić e2e na poziomie samych serwisów i jsona, a nie koniecznie co się wyświetli w UI. Takie testy są prawie że tak samo użyteczne, a 100 razy łatwiejsze w utrzymaniu.

Kontekst jest taki: robimy dość duży system bankowy, w tle pracuje na ten moment jakieś 15 naszych serwisów + kilka innych, od których jesteśmy zależni + rozrośnięty ponad miarę frontend + zależności typu komunikacja z innymi bankami. Ze względu na złożoność interakcji tego wszystkiego, testy e2e wydają się być dość prostym sposobem na przetestowanie, czy wszystko faktycznie do siebie pasuje, bez mockowania żadnych zależności.

Testy akceptacyjne oczywiście mnóstwo ok, piszemy ich sporo, Wiremock 4ever, ale no właśnie - mockowanie zostaje.

Obecnie mamy tych testów selenium grubo ponad 200, przy czym niektóre są dość rozbudowane. Od kiedy przerzuciliśmy to na SeleniumBox to przynajmniej całość leci jakieś 1:30h, zamiast dotychczasowych 6 - więc problem powolnego feedbacku jest po części rozwiązany. Jak pisałem - moje wątpliwości co do sensu całego przedsięwzięcia związane są z tym, że błędy w raporcie to u nas w większości kwestia złych danych testowych lub niedopasowania testów do zmian w implementacji, przy czym prostowanie tego kosztuje naprawdę sporo czasu.

Uznaliśmy, że ok 60% tych testów należy deaktywować, a skupić się jedynie na utrzymaniu zbioru funkcjonalności, które koniecznie muszą działać.

Ogólnie uważam, że idea sama w sobie może i jest dobra, ale należy się dwa razy zastanowić czy oraz przede wszystkim co testować. Łatwo można skończyć z hałdą kodu, który trzeba jakoś utrzymywać, natomiast zespół zadziwiająco szybko przywyka do tego, że raport z jenkinsa jest nieco czerwony :)

W poprzedniej hucie były wykorzystywane testy automatyczne wykonywane przez Selenium, ale tylko na preprodukcji systemu do testowania wybranych funkcjonalności, które wykorzystywały integracje z innym systemem produktowym. Testy były uruchamiane na preprodukcji przed wdrożeniem wydania na produkcje. Obecna huta jest na etapie dywagacji czy testy automatyczne są do czegoś potrzebne:)

Korzyść z Selenium jest, ale jak była mowa w którymś z postów powyżej koniecznie trzeba się zastanowić co się chce testować i po co.

testy na selenium wg mnie winne być testami akcpetacyjnymi, które testują ścieżkę krytyczną, czyli czy użytkownik może się zalogować (i jeśli mówimy o sklepie) wejść na 1 z rzędu produkt i go kupić. Tyle.