Testy E2E Dla Backend Developera 馃檮. Czy warto鉂撯潛

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.

0 0 vote
Article Rating
Subscribe
Powiadom o
guest
0 komentarzy
Inline Feedbacks
View all comments