Testowanie E2E: A Tutorial and Architectural Guide
Testy end-to-end (E2E) pomagają w walidacji najważniejszych przepływów w Twojej aplikacji, takich jak żądania logowania użytkowników. W przypadku rozwoju front-end, testy E2E pomagają zweryfikować, czy poprawny UI został zaprezentowany. Dla rozwoju back-end, testy E2E pomagają zweryfikować czy ważny przepływ w twoich usługach back-end zwraca oczekiwane wyjście.
Ten post wprowadzi cię do testowania E2E i da ci wskazówki do działania. Wyjaśnimy również jak pisać testy wielokrotnego użytku, aby można było je łatwiej wykorzystać do tworzenia testów E2E. Jak być może wiesz, testy E2E są często główną frustracją dla deweloperów, ponieważ wymagają wiele wysiłku, aby je napisać, uruchomić i utrzymać.
Po pierwsze, spójrzmy na to, gdzie testy E2E znajdują się w piramidzie testowania oprogramowania.
Miejsce testów E2E w piramidzie testowania
Patrząc na piramidę testowania, znajdujemy cztery główne typy testów, które pomagają nam zagwarantować jakość kodu:
- Testy E2E pomagają zweryfikować ścieżki o wysokiej wartości w twojej aplikacji. Innymi słowy, pomagają one zweryfikować historie użytkowników, ponieważ często reprezentują one przepływy w aplikacji.
- Testy integracyjne pomagają zweryfikować integrację wielu funkcji lub komponentów. Testy integracyjne mogą powiedzieć Ci, czy Twój kod działa spójnie z innymi funkcjami.
- Testy jednostkowe pomagają zweryfikować logikę biznesową funkcji. Testy jednostkowe są najbardziej podstawową formą testowania, i zapewniają, że logika biznesowa jest poprawna.
- Na koniec, nie możemy zapomnieć o analizie statycznej lub testach statycznych. Testy statyczne pomagają znaleźć literówki lub błędy typu.
Zgodnie z tą piramidą, większość testów powinna być testami jednostkowymi, z mniejszą ilością testów integracyjnych i jeszcze mniejszą ilością testów E2E. Jednak nadal ważne jest, aby weryfikować przepływy w aplikacji. Testy E2E są trudne do utrzymania i wymagają dużo wysiłku. Dlatego też, weryfikuj tylko najważniejsze przepływy za pomocą testów E2E. Inne rodzaje testów, takie jak integracyjne i jednostkowe powinny już dać ci wystarczające zaufanie do twojej bazy kodowej.
Różne strategie testowania E2E
Pozwól mi powiedzieć, że istnieją różne strategie. Możemy wybrać pomiędzy poziomym testowaniem E2E i pionowym testowaniem E2E. Obie strategie są warte poznania, ponieważ pozwalają na testowanie różnych scenariuszy. Dowiedzmy się co robi każda z tych strategii.
Strategia #1: Pionowe testowanie End-to-End
Ta strategia skupia się na testowaniu wszystkich warstw piramidy testowania. Obejmuje ona testy jednostkowe, testy integracyjne i testy UI. Twoim celem jest przetestowanie komponentu na poziomie granularnym przy użyciu testów jednostkowych, przetestowanie jak komponent zachowuje się podczas interakcji z innymi komponentami przy użyciu testów integracyjnych, a na koniec zweryfikowanie zachowania komponentu, gdy użytkownicy wchodzą w interakcję poprzez UI.
Najczęściej, chcesz użyć potoku ciągłej integracji, aby zautomatyzować te testy dla każdego commitu kodu lub pull requestu.
Strategia #2: Poziome testowanie End-to-End
Poziome testowanie E2E skupia się na weryfikacji kompletnego przepływu użytkownika. Oto przykładowy przepływ dla sklepu internetowego:
- Otwórz stronę produktu
- Wybierz rozmiar produktu
- Dodaj produkt do koszyka
- Przejdź do kasy
- Wypełnij dane adresowe i informacje o płatności
- Zakończ płatność
- Pokaż ekran potwierdzenia zakupów
W tym miejscu chcemy zweryfikować każdą transakcję przepływu użytkownika. Często ten typ testów weryfikuje interakcję pomiędzy różnymi aplikacjami i weryfikuje zmiany stanu dla tych aplikacji.
Zauważ, że tego typu testy są drogie do napisania. Zdefiniowanie przepływów użytkownika i napisanie tych testów wymaga sporo czasu. Dlatego należy skupić się na krytycznych ścieżkach transakcji dla aplikacji.
Należy jednak pamiętać, aby testować te krytyczne przepływy użytkownika dla różnych warunków. Ta strategia pozwala na uzyskanie pełnego obrazu odporności przepływu użytkownika. Warunki te obejmują:
- Złożone scenariusze czasowe: Na przykład, bilet na koncert jest dostępny dla użytkownika tylko przez 15 minut.
- Różne dane wejściowe lub brakujące dane.
- Przerwy w przepływie: Użytkownik decyduje się opuścić stronę kasy, aby wyświetlić inną stronę produktu. Na przykład, musimy sprawdzić, czy komponent zapisuje stan kasy.
Następnie, dowiedzmy się kiedy pisać testy E2E.
Kiedy pisać testy E2E
Możesz nie wiedzieć, że testy E2E są drogimi testami do uruchomienia w twoim potoku ciągłej integracji. Często wymagają wielu przygotowań, takich jak tworzenie bazy danych, która naśladuje dane produkcyjne. Dodatkowo, czasami reprezentują one czasochłonne przepływy w aplikacji. Dlatego mogą być powolne i wymagać więcej zasobów do wykonania.
Użyj testów E2E do weryfikacji najważniejszych przepływów w Twojej aplikacji. Przykłady przepływów o wysokiej wartości obejmują:
- Logowanie i wylogowywanie
- Rejestracja nowego użytkownika
- Dodaj element do koszyka
- Zmień hasło
- Dowolne inne ważne przepływy związane z Twoją usługą
Nie zapomnij jednak zweryfikować logiki biznesowej, którą piszesz za pomocą testów jednostkowych i integracyjnych. Połączenie testów jednostkowych i integracyjnych powinno dać Ci dużo pewności co do jakości Twojego kodu. Testy E2E pomagają zwiększyć tę pewność dla ścieżek krytycznych.
Oto kilka praktycznych wskazówek dotyczących pisania testów E2E.
Tips for Writing E2E Tests
Focus on Writing Reusable Tests
Pierwszą i najważniejszą wskazówką jest pisanie małych, niezależnych, wielokrotnego użytku testów i komponentów. Pozwala to na łączenie wielu małych komponentów w celu stworzenia kompletnego przepływu użytkownika end-to-end w łatwiejszy sposób. Zamiast pisać wiele niestandardowych komponentów, które mają być używane tylko przez testy E2E, skup się na pisaniu komponentów wielokrotnego użytku.
Pisanie małych, niezależnych komponentów pomaga w ponownym użyciu kodu i zmniejsza czas rozwiązywania błędów. Ponadto, łatwiej jest aktualizować małe komponenty, kiedy funkcjonalność lub przepływy użytkownika ulegają zmianie.
Zawsze rozważ powód pisania testu E2E
Kiedy chcesz objąć dany przepływ testem E2E, zastanów się, czy warto go objąć. Testuj tylko wartościowe przepływy użytkownika za pomocą testów E2E. Na przykład, nie powinieneś testować, czy komunikat o błędzie jest wyświetlany, gdy użytkownik wprowadzi nieprawidłowy adres e-mail. Jest to zdecydowanie zbyt prosty przypadek użycia, który nie pasuje do testu E2E. Ten wymóg można po prostu przetestować za pomocą testu jednostkowego.
Z drugiej strony warto przetestować, czy strona logowania przekierowuje użytkownika do właściwej strony aplikacji po pomyślnym zalogowaniu. Jest to cenny przepływ dla Twoich użytkowników, aby mogli korzystać z aplikacji. W skrócie, zawsze bierz pod uwagę powód pisania testu E2E.
Testy E2E nie powinny zależeć od szczegółów implementacji
Nie chcesz aktualizować testów E2E za każdym razem, gdy zmieniasz szczegóły implementacji dla danego przepływu. Dlatego chcesz pisać komponenty, które pozwalają na abstrakcję szczegółów implementacji. Testy E2E stają się dużo łatwiejsze w utrzymaniu i przyjemniejsze do pisania, gdy szczegóły implementacji są ukryte w komponentach. W skrócie, testy E2E powinny być niezależne od szczegółów implementacji.
Następnie, przyjrzyjmy się pułapkom testów E2E.
Pitfalls of E2E Testing
Oto lista powszechnych pułapek związanych z testami E2E:
- Testy E2E nie powinny próbować testować jak najwięcej za jednym zamachem. Często programiści piszą ogromne testy E2E, które weryfikują każdy aspekt przepływu użytkownika. Utrzymuj rzeczy proste i weryfikuj najważniejsze aspekty przepływu użytkownika. Na przykład, dla przepływu logowania, wystarczy sprawdzić, czy użytkownik został przekierowany na stronę aplikacji. Ułatwi to programistom utrzymanie i aktualizację testów E2E.
- Gdy test E2E zakończy się niepowodzeniem, znalezienie dokładnej przyczyny niepowodzenia może być trudne. Jednakże, można zmniejszyć wysiłek związany z debugowaniem wymagany przez pokrycie logiki biznesowej testami jednostkowymi i integracyjnymi. Niektóre narzędzia zapewniają również dobrą analizę przyczyn źródłowych, w tym zrzuty ekranu i logi konsoli nieudanych kroków testowych, co może skrócić czas rozwiązywania problemów.
- Testy E2E wymagają znacznej ilości czasu w twoim potoku ciągłej integracji (CI). Mogą one zablokować Twój potok CI, co spowalnia ogólny rozwój. Oznacza to, że być może będziesz musiał zainwestować w swój potok CI, aby mieć kilka dodatkowych potoków do uruchamiania testów.
- Testy E2E są ciągłym wysiłkiem. Za każdym razem, gdy dodawana jest nowa funkcjonalność lub stara funkcjonalność ulega zmianie, prawdopodobnie będziesz musiał zaktualizować swoje testy E2E. Jednakże, możemy zredukować ten wysiłek poprzez pisanie komponentów wielokrotnego użytku, które abstrahują szczegóły implementacji. Dodatkowo, niektóre narzędzia używają AI, aby pomóc dostosować testy, kiedy kod się zmienia, redukując utrzymanie testów.
Teraz, spójrzmy krótko na różnice pomiędzy testowaniem systemowym i testowaniem E2E.
Testowanie systemowe vs. Testowanie E2E – Jaka jest różnica?
Więc, jaka jest różnica pomiędzy testowaniem systemowym i testowaniem E2E? Testowanie systemu koncentruje się na walidacji zarówno wymagań funkcjonalnych jak i niefunkcjonalnych. Często, jest ono wykonywane przez zewnętrzny zespół, który traktuje aplikację jak czarną skrzynkę. Innymi słowy, nie wiedzą nic o funkcjonowaniu aplikacji poza wymaganiami, które powinna spełniać.
Jednakże, ta forma testowania jest często mylona z testowaniem E2E, ponieważ testowanie systemowe jest formą testowania E2E. Chociaż, testowanie systemowe weryfikuje znacznie więcej niż testowanie E2E. Na przykład, testowanie systemu mierzy skalowalność, wydajność lub niezawodność. Podczas gdy testowanie E2E skupia się na poprawnym zakończeniu przepływów użytkownika.
Na koniec, podsumujmy wnioski z tego artykułu.
Wnioski na temat E2E
Testy end-to-end są całkiem potężne, ponieważ pomagają w walidacji przepływów użytkownika o wysokiej wartości lub historii użytkownika. Pomagają one zagwarantować jakość twojej aplikacji.
Jednakże, pisanie i utrzymywanie testów E2E może wymagać znacznego czasu i wysiłku. Możliwe jest zmniejszenie tego wysiłku poprzez pisanie małych, wielokrotnego użytku komponentów, które abstrahują szczegóły implementacji. Niektóre narzędzia pomagają również tworzyć bardziej odporne testy poprzez użycie AI lub wielu atrybutów do identyfikacji każdego elementu. Dzięki temu, nie trzeba aktualizować testów E2E za każdym razem, gdy zmieniają się szczegóły implementacji dla przepływów użytkownika o wysokiej wartości. Ponadto, komponenty wielokrotnego użytku pozwalają na łączenie tych komponentów w celu łatwego tworzenia przepływów testowych E2E.
Testy E2E powinny obejmować najważniejsze przepływy Twojej aplikacji. Testują przepływy, które Twoi użytkownicy i klienci wykonują, aby uzyskać wartość z Twojej aplikacji. Jeśli nie będą mogli się zalogować lub dodać produktu do koszyka, opuszczą stronę (jeśli będą mogli) lub zadzwonią do pomocy technicznej, jeśli będą zmuszeni do korzystania z Twojej aplikacji. Na przykład, chcesz pokryć przepływ logowania i wylogowania, ale jesteś mniej zainteresowany weryfikacją komunikatu o błędzie po wprowadzeniu złego adresu e-mail.
W końcu, testy E2E powinny być zabawne do napisania. Nie powinny wymagać dużo czasu i wysiłku, aby je napisać i utrzymać. Zachowaj prostotę testów E2E i skup się na komponentach wielokrotnego użytku, a zobaczysz wspaniałe rezultaty!
Ten post został napisany przez Michiela Muldersa. Michiel jest zapalonym programistą blockchain, który uwielbia pisać treści techniczne. Oprócz tego uwielbia uczyć się o marketingu, psychologii UX i przedsiębiorczości. Kiedy nie pisze, prawdopodobnie delektuje się belgijskim piwem!
.