Testy End-to-End - czy warto?

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.