Testowanie JS - podstawy
- Czas potrzebny na przeczytanie:4 minuty
- Opublikowane:
Jakiś czas temu wysłałem do osób, które są zapisane do newslettera, krótką ankietę. Zawierała ona jedno, kluczowe pytanie - Czego chcesz się nauczyć? Mogliście wybrać proponowane przeze mnie tematy lub napisać coś od siebie. Ku mojemu zaskoczeniu, dużą przewagą, wygrało Testowanie!
Bez zbędnego gadania, zaczynajmy!
Dlaczego warto?
Już kilka razy w życiu słyszałem coś w stylu:
Testy? A komu to potrzebne?
Piszę super czysty kod w nowoczesnych frameworkach, niepotrzebne mi testy. Działa? Działa.
Lub jeszcze inny przypadek:
Testy? Nie mamy na to czasu, deadline już za chwilę, a mamy do zrobienia jeszcze masę funkcjonalności.
Przeklikaj się przez stronę to będą testy e2e.
A więc to wszystko prawda? Czy testy to starta czasu?
Podczas tworzenia aplikacji bardzo często trafiamy na najróżniejsze błędy. Najlepiej by było łapać je jak najwcześniej, żeby przypadkowo nie wypłynęły na produkcję.
Największą zaletą testów jest właśnie pewność, że nasz kod będzie działać tak, jak tego oczekujemy. Oczywiście nie mamy nigdy 100% pewności, że coś się nagle nie wysypię, ale otestowany kod to zawsze pewniejszy kod.
Czy to już wszystko? Nie! Testy to również lepsze zrozumienie problemu, obsłużenie wielu różnych przypadków związanych z logiką biznesową. Pomagają nam one tworzyć lepszy kod - łatwiej otestować dobrze rozłożone komponenty niż wielki kombajn. I na sam koniec, testy pozwalają nam lepiej zrozumieć kod i dostarczają warstwę dokumentacji.
Rodzaje testów
Przez wiele lat uznawana była tzw. piramida testów. Była, no właśnie, aż do czasu pojawienia się The Testing Trophy, zaprezentowanego przez Kent C. Doddsa.
Wspomniane trofeum skupia się, w przeciwieństwie do piramidy, na testach integracyjnych. Przyjrzyjmy się trochę bliżej rodzajom testów i ich rozłożeniu.
Statyczne
Ze statycznym testowaniem mogłeś/aś się już spotkać wcześniej w swoim kodzie. Do tej grupy testów możemy zaliczyć takie narzędzia jak np. ESlint. Pozwala nam on, podczas developmentu, wyłapać najróżniejsze błędy aplikacji. Bez niego ciężko sobie wyobrazić pisanie kodu.
Kolejnym narzędziem, a właściwie językiem, jest uwielbiany przeze mnie TypeScript. Pozwala Ci on na statyczne typowanie, które nie jest dostępne w czystym JS. To właśnie dzięki niemu oszczędzamy sobie wielu godzin na debugowaniu głupich błędów. Założeniem TypeScripta jest to, o czym wcześniej wspominałem, czyli pewność, w tym przypadku typów.
Jednostkowe
Testy jednostkowe zaliczamy do tych najprostszych. Skupiają się one na testowaniu pojedynczej jednostki kodu, na przykład jakieś funkcji. Można by powiedzieć, że są one wyizolowane, tak, aby przetestowany kod działał w każdym kontekście.
Najłatwiejszym przykładem może być funkcja add(), która przyjmuje dwie liczby, dodaje je i po prostu zwraca. W naszym teście jednostkowym chcemy, aby po podaniu argumentów 2 i 3 funkcja zwracała wynik 5.
Przykład technologii: Jest
Integracyjne
Załóżmy, że mamy kilka pomniejszych funkcji, które wcześniej przetestowaliśmy używając testów jednostkowych. Wszystko jest świetnie, nasze testy przechodzą, aż do czasu gdy te funkcje będziemy chcieli wykorzystać w jakieś większej jednostce kodu, możemy ją nazwać komponentem.
Testy integracyjne odpowiadają za to, żeby nasze funkcje współpracowały ze sobą w odpowiedni sposób, tak aby nasz komponent zadziałał.
Przykład technologii: React Testing Library
End to End
Te testy są na samej górzej naszego trofeum, wspominałem Ci o nich już na początku - Przeklikaj się przez stronę to będą testy e2e.
Testy End to End, zwane również e2e, skupiają się użytkowniku naszej aplikacji, bo na sam koniec to tylko on się liczy. Oczywiście nie robimy ich sami tak jak w przykładzie, pomaga nam taki robot, który stara się odwzorować kolejne ruchy użytkownika na stronie.
Jak może wyglądać taki test? Załóżmy, że mamy jakiś formularz logowania. W testach e2e nasz robot musi odpowiednio wprowadzić dane do inputów, a następnie zatwierdzić je przycisk Zaloguj się. Po zalogowaniu powinniśmy zobaczyć tekst Zalogowano.
Przykład technologii: Cypress
Kompromisy
Po poznaniu rodzajów testów możesz mieć wrażenie, że testy e2e są najlepsze i tylko je powinniśmy pisać, w końcu na samym końcu jest użytkownik. To prawda, na samym końcu jest użytkownik, ale to nie znaczy, że powinniśmy pisać tylko i wyłącznie te testy.
Podczas testowania musimy iść na kompromis pomiędzy kosztem testów a wspominaną już pewnością. Im wyżej jesteśmy w trofeum, tym większa jest nasza pewność, ale wiążą się z tym pewne bolączki. Testy im wyżej w hierarchii tym są droższe w utrzymaniu i wolniejsze w działaniu.
Wszystko zależy od tego, co chcemy testować. Korzystając z testów jednostkowych, niekoniecznie chcemy sprawdzać typ parametru, robi to za nas TypeScript. Tak samo w drugą stronę, w testach e2e nie będziemy testować czy dropdown się odpowiednio wyświetlił, będziemy się w nich skupiać na szczególnie ważnej logice biznesowej.
Jak to wszystko ma się do naszego trofeum testów?
Kompromisem pomiędzy kosztem a pewnością wydają się testy integracyjne, których będziemy pisać najwięcej.
Write tests. Not too many. Mostly integration.
~ Guillermo Rauch.
Podsumowanie
Przez następne tygodnie, na tym blogu, pokażę Ci jak testować kod za pomocą wspomnianych dziś rodzajów testów. Zaczniemy od Jest, następnie przejdziemy do React Testing Library, a skończymy na testach e2e w Cypressie.
Dzisiejszy artykuł to takie wprowadzenie w świat testów (i do tej serii), bazuje na ideologii wspomnianego Kenta, gorąco polecam sprawdzić jego bloga!
