Zapewnienie poprawności aplikacji z punktu widzenia zespołu, który tę aplikację rozwija jest MEGA istotne. Nie wiem jak podkreślić tą istotność, dlatego użyłem wielkich liter + pogrubienia. W jaki sposób zapewnić tę poprawność? Jednym z rozwiązań jest wprowadzenie testów end to end. Ten rodzaj testowania ma jednak swoje kompromisy…
Cześć 
W dzisiejszym artykule:
Testy End to End – czym są?
Testy end to end (E2E), akceptacyjne, czy też funkcjonalne, to wszystko sprowadza się do jednego – do testów weryfikujących pewne zachowanie aplikacji całościowo. Ten rodzaj testowania weryfikuje funkcjonalność od początku do końca (end to end), symulując zachowanie użytkowników lub procesu. W pozostałej części artykułu, słownictwo: testy e2e, akceptacyjne czy funkcjonalne, będę używał wymiennie.
Jeżeli nie masz doświadczenia z tego rodzaju testami, to możesz wyobrazić to sobie jako użytkownika klikającego twoją aplikację i weryfikującego czy zostały spełnione założone wyniki. Oczywiście różnica jest taka, że w przypadku testów automatycznych, kroki te wykonują się same i mogą być odpalone w dowolnym momencie.
Wydaje się to być idealnym rozwiązaniem? No nie do końca. Trzeba pamiętać, że testy te, po pierwsze trzeba napisać. A i to nie wszystko.. bo jeżeli pracujesz w tej branży nieco dłużej to wiesz doskonale, że aplikacje ewoluują. Z czasem będą dochodziły nowe wymagania, które trzeba zaimplementować. Obecna implementacja też nie jest wieczna. Pod wpływem zmieniających się trendów ona również wymaga konserwacji (lub po prostu refaktoru), a co za tym idzie – musimy uwzglednić przy tym testy, które już posiadamy.
Dlaczego testy E2E są popularne / zachęcające?
Nurt testów akceptacyjnych zyskał dużą popularność szczególnie wśród ludzi z biznesu, ale nie tylko. Nawet słynna piramida testów uwzględnia ten rodzaj weryfikacji. Dlaczego tak jest? Z punktu widzenia biznesu zachęcająca jest świadomość, że taki test symuluje realne zachowanie użytkownika. A to prowadzi do kolejnej zalety, czyli poczucia bezpieczeństwa, że dany scenariusz działa prawidłowo. Z punktu widzenia developera plusem jest ich łatwość pisania – nie ma potrzeby pisania mocków lub symulowania komunikacji z bazą danych czy brokerem wiadomości.
Jakie są wady testowania E2E?
Oprócz wcześniej już wspomnianego wysiłku potrzebnego na napisanie takich testów i ich utrzymanie jedną z poważniejszych wad jest długość czasu wykonania. Nikt nie lubi oczekiwania, a testy e2e dodają solidną cegłę do tego procesu. Oczywiste jest, że lokalnie nie będziemy tych testów odpalać co chwilę (o ile w ogóle je odpalimy), natomiast przed wdrożeniem na konkretne środowisko dobrze byłoby się upewnić, że wszystko działa. I dzięki takim testom nasz pipeline wdrożeniowy właśnie się wydłuża.
Kolejnymi wadami są trudność debugowania oraz fałszywe negatywy. Zacznijmy od pierwszego. Załóżmy, że napisałeś test e2e dla funkcjonalności zakupu produktu w sklepie. Proces polegał na zalogowaniu się na konto, dodanie produktu do koszyka a następnie sfinalizowanie zakupu (dokonanie płatności). Test się wyłożył, ale gdzie dokładnie? Testy akceptacyjne nie pozwolą na szybką izolację wystąpienia problemu. Będziesz zmuszony odpalić test jeszcze raz lub samemu wykonać dany scenariusz, żeby wiedzieć co poszło nie tak. A i to sprawi, że będziesz musiał zaglądnąć w logi serwera, aby zweryfikować co dokładnie poszło nie tak.
Przechodząc do fałszywych negatywów. Ponownie załóżmy ten sam proces zakupu produktu. Twoja aplikacja działa poprawnie natomiast jeden z mikroserwisów z katalogiem produktów wyłożył się przed testami i znów test nie przeszedł. Ponownie wykorzystujesz czas na znalezienie błędu w aplikacji, którego de’facto nie ma.
Kiedy i czy warto pisać testy E2E?
Jeżeli miałbym odpowiadać na takie pytanie, to moją odpowiedzią byłoby pytanie w przeciwnym kierunku: jaki jest kluczowy scenariusz biznesowy? Czyli, jaka jest wartość biznesowa. Ile firma zarabia na danej funkcji, czy błędne działanie może spowodować istotne straty, jak często funkcja jest używana.
Szczera rozmowa z biznesem na ten temat pozwoli nam napisać mniej testów. Testy te będą jednak krytyczne i dadzą komfort psychiczny zarówno w kwesti poprawności jak i faktu, że nasz deployment nie ciągnie się godzinami. Bardzo ważne jest aby umieć zadawać dociekliwe pytania przy rozmowie z biznesem, np. co się stanie, z punktu widzenia biznesu, jeżeli ta funkcjonalność nie będzie miała testu akceptacyjnego? (jeżeli był nacisk aby taki test napisać)
Na pytanie z tego akapitu nie da się odpowiedzieć w sposób jednoznaczny. Jeżeli będziesz mieć kiedykolwiek możliwość decyzji o pisaniu takich testów, to staraj się patrzeć na to przez pryzmat wartości biznesowej. Jeżeli masz zespół testerów, który manualnie kilka scenariusze, to może faktycznie warto byłoby to zautomatyzować. Napisać kilka przykładowych scenariuszy i zobaczyć jaką wartość to przyniesie. Wtedy to testerzy mogliby zająć się utrzymywaniem testów. Na początku będzie ciężko bo trzeba nauczyć się nowych narzędzi i przyzwyczaić wszystkich do pewnych zmian, ale z czasem może (nie musi) przynieść to dużą wartość biznesową. Jaką? Jeżeli klient będzie chciał wdrożyć nową wersję produktu, to z czasem wystarczy odpalenie testów aby przetestować krytyczne ścieżki i z dużym komfortem możemy to wdrażać.
Testy E2E moim okiem
Rzeczywistość jest taka, że na ilu projektach byłem, to testów end to end nie musiałem pisać nigdy. Nie oznacza to, że ich nie pisałem. Pojawiały się próby, gdzie biznes chciał aby takie testy się pojawiły, ale zazwyczaj kończyło się to tylko na próbach.
Moim zdaniem backend developer powinien umieć napisać testy end to end. Powinien znać narzędzia, które wspomagają ten proces. A czy powinien pisać? To już zależy od klienta dla którego pracujemy. Dla krytycznych funkcjonalności, które rzadko się zmieniają a przynoszą dużą wartość powinniśmy przynajmniej rozważyć takie testy. Jednak wydaje mi się, że testy jednostkowe oraz integracyjne w dużej mierze są wystarczające a dodatkowa warstwa testów wcale nie okazuje się tak bardzo pomocna.
Pisanie testów akceptacyjnych to nie jest tylko wyklepanie pewnego scenariusza. To też umiejętność miękka. Jako osoba pisząca scenariusz muszę wejść w buty klienta (osoby, która korzysta z oprogramowania, które rozwijamy), a najlepiej jest to zrobić przez rozmowę. A sama umiejętność rozmowy oraz wyciąganie kluczowych informacji to już soft skill 🙂 . Warto też pamiętać, że jeżeli będziesz umiał pisać testy e2e, to Twoja wartość rośnie. Jeżeli klient chce na projekcie takie testy to Ty, jako osoba majaca tą umiejętność będziesz bardziej atrakcyjny. To natomiast, przy odpowiedniej negocjacji przekłada się na większe pieniądze. W końcu nie pracujemy charytatywnie…
Podsumowanie
Nie da się stwierdzić jednoznacznie czy warto pisać testy e2e. Odpowiedź na to pytanie brzmi to zależy. Jest to zależne od klienta i wartości biznesowej, jaką dany test ma spełnić. Jako developerzy powinniśmy starać się ochładzać zapędy biznesowe do pisania tego rodzaju testów. Nie mówię, że całkowicie mamy ich nie pisać, ale zawsze powinniśmy przeprowadzić szczerą rozmowę z ludźmi na szczeblu, aby się dowiedzieć czy faktycznie dany scenariusz przynosi wartość.
Źródła:
Za tydzień
Już ostatni wpis w tym roku!! Porozmawiamy o springu i adnotacjach do wstrzykiwania zależności.