Gratulacje! Tworzenie testów end-to-end (E2E) to dość zaawansowany temat, który może okazać się wartościowy dla Twojego projektu. Testy te potrafią wyłapywać potencjalne problemy przed scaleniem zmian w gałęzi głównej – kiedy jeszcze daleko do wdrożenia do środowiska produkcyjnego. Im wcześniej wykryjesz bug, tym łatwiej będzie Ci go naprawić. Testy E2E pozwalają na szeroko zakrojoną weryfikację wszelkich zmian zaraz po ich udostępnieniu.

Czym są testy end-to-end

Testy E2E to skrypty, które „używają” aplikacji tak, jak zrobiłby to użytkownik. Otwierają przeglądarkę, ładują adres URL, klikają w elementy interfejsu użytkownika (UI), na przykład przyciski, i oczekują pewnych rezultatów. Testy przeprowadza komputer i są one dużo szybsze i mniej zawodne od ludzi. Poza tym nigdy się nie nudzą.

Ich jedynym słabym punktem jest to, że potrzebują precyzyjnych poleceń i zdarza się, że ich zaprogramowanie jest bardziej skomplikowane niż funkcja, którą mają testować. Pisanie testów stanowi element programowania i jest powiązane z aplikacją, która ma być testowana. Mimo to jest to zadanie, do którego wielu programistów nie podchodzi z entuzjazmem. Jeżeli rozwiniesz się w tej dziedzinie, może stać się to Twoją wyjątkową kompetencją, która pozwoli Ci błyszczeć w zawodzie.

Dobierz odpowiednie narzędzia!

Pakiet E2E można zbudować na wiele różnych sposobów:

• Cypress
• Playwright
• Protractor
• Selenium
• TestCafe

Sytuacja wygląda tu tak samo jak w przypadku innych decyzji dotyczących stosów technologii: dobrze jest gruntownie zapoznać się z wszystkimi możliwościami. Każdy pisany przez Ciebie test będzie ściśle związany z wybraną przez Ciebie platformą. Istnieje możliwość migracji z jednego narzędzia do testowania do drugiego, ale jest to przedsięwzięcie przypominające wymianę frameworka na frontendzie.

Moje doświadczenia ograniczają się głównie do Protractora, niedocenianego rozwiązania opartego na Angular. Aktualnie przeprowadzam migrację testów do Cypress i jestem pod wrażeniem postępu w dziedzinie narzędzi do testowania, do jakiego doszło na przestrzeni minionych lat. A Ty z jakiego narzędzia E2E chcesz korzystać w swoim kolejnym projekcie? Daj mi znać, biorąc udział w ankiecie.

Proste testy na lokalnym sprzęcie

Niech Twoje pierwsze testy będą wręcz banalne. Weź dowolny lokalny testowy URL, jaki masz pod ręką, i uruchom na nim swoje skrypty. Nie musisz nawet sprawdzać workflow aplikacji. Po prostu napisz kilka testów, po jednym dla każdej trasy, i sprawdź, czy na danej stronie pojawiają się elementy interfejsu UI. Możesz na przykład sprawdzić:

• on /login– czy pojawiają się pola wprowadzania hasła i nazwy użytkownika,
• on /product/12 – czy wyświetlana jest nazwa produktu,
• itd.

Nawet przy pomocy tak prostych testów możesz udowodnić, że:

1. aplikacja się uruchamia, a wszystkie trasy wyświetlają się razem z kluczowymi elementami interfejsu UI;
2. potrafisz tworzyć testy E2E.

I tym sposobem temat E2E zacznie się rozkręcać – zespół będzie mieć kilka testów do wyboru, a jeden z jego członków (czyli Ty) będzie chętny i zdolny do pisania kolejnych!

Podziel się dobrą nowiną z zespołem

Nie będziesz musiał być tu zbyt nachalny, przynajmniej na początku. Upewnij się tylko, że wszyscy wiedzą, że testy E2E są dostępne, i doprowadź do sytuacji, w której od każdego programisty oczekiwać się będzie, że przeprowadzi je przed scaleniem jakichkolwiek zmian w gałęzi głównej. Na tym etapie zauważysz wszelkie różnice między lokalnymi konfiguracjami używanymi przez Twoich kolegów po fachu – inne domeny lub porty, z których korzystają lokalnie. Możesz opanować sytuację przez dopilnowanie, żeby wszyscy używali tego samego adresu URL, albo przez sprawienie, że URL testowy będzie łatwy w konfiguracji, a nie zakodowany „na twardo”. Oba podejścia są w porządku. Ja zdecydowałem się na dopilnowanie, aby wszyscy korzystali z tego samego adresu URL localhosta; w moim przypadku zespół nie miał nic przeciwko.

Kolejnym krokiem jest przetestowanie ścieżki happy path w odniesieniu do workflow – czyli jak powinna działać aplikacja, kiedy wszystko funkcjonuje, jak należy. Innymi słowy – piszesz testy, które sprawdzają, czy przycisk „Dodaj do koszyka” rzeczywiście dodaje wybrane produkty do koszyka i czy przycisk „Kupuję i płacę” kieruje użytkownika na stronę dostawcy usług płatniczych. Testy takie trudniej się pisze, ale sprawdzają najważniejsze elementy aplikacji. Skrypty te powinny pomóc Ci w przekonaniu kolegów o przydatności E2E. A Twoje testy będą stawać się coraz bardziej zaawansowane.

Co dalej

Jeśli masz jakiekolwiek pytania lub wątpliwości w temacie testów E2E, podziel się nimi w komentarzach! Przeczytam je i postaram się odpowiedzieć na nie jak najlepiej. A jeśli jeszcze mało Ci czytania, zapraszam do zapoznania się z moim artykułem o zarządzaniu delikatnym przestarzałym kodem.