# Jak pisać testy jednostkowe Początkującym programistom starsi koledzy po fachu często radzą, aby testowali swój kod. To dobra rada – zobaczmy, jak wprowadzić ją w życie! ## Czym są testy jednostkowe Testy pozwalają na ustalenie wyraźnych oczekiwań w stosunku do kodu. Dają Ci możliwość maszynowego sprawdzenia, czy Twój kod spełnia te oczekiwania. Jest to program, który weryfikuje Twój program. W przypadku projektów opartych na JavaScript będziesz zwykle korzystał z biblioteki testującej takiej jak: * Jest, * Jasmine, * Chai. Są to jednak tylko narzędzia. Najważniejsze, żebyś miał na podorędziu coś, co w sposób automatyczny zweryfikuje Twoją aplikację. ![Image description](https://cdn.hashnode.com/res/hashnode/image/upload/v1651040375625/pl0KTpDsy.jpeg) ## Jak testy jednostkowe mogą Ci pomóc Pisanie testów ułatwi Ci życie na cztery sposoby: 1. Jest to szybki i sprawdzony sposób na sprawdzenie, czy kod działa, jak należy. Nie musisz myśleć o przypadkach brzegowych, zajmą się nimi testy jednostkowe. 2. Dobre pokrycie kodu to zawór bezpieczeństwa, który pozwala na nieco śmielszą refaktoryzację kodu. Zwiększysz w ten sposób prawdopodobieństwo tego, że Twoja baza kodu będzie znajdować się w niezmiennie dobrym stanie. 3. Pisanie testów _jednostkowych_ zmusza Cię do myślenia o jednostkach i o tym, jak rozdzielić między nie odpowiedzialność: w rezultacie Twój kod stanie się modułowy i łatwiej będzie go utrzymać. 4. Testy jednostkowe zrobią z Ciebie szybszego programistę. Najpierw będziesz musiał zainwestować czas na stworzenie przypadku testowego – pozwoli Ci to jednak potem na bezwysiłkowe uruchamianie go raz za razem. Inwestycja przyniesie Ci dywidendy już we wstępnej fazie programowania. ## Zbuduj strukturę Zanim zabierzesz się za testowanie funkcjonalności, upewnij się, że możesz przetestować *cokolwiek*. Zainstaluj bibliotekę testującą i skonfiguruj testujący skrypt. Kiedy będziesz już coś miał, zacznij tworzyć rusztowanie pod niektóre z Twoich testów. Musisz przyjąć konwencję nazewnictwa. Jeśli na przykład Twój kod znajduje się w: `my-project/plane-ticket.js`, nazwą Twojego kodu testującego może być: `my-project/plane-ticket.spec.js`. Zbuduj wszystko, co potrzebne do przetestowania danej klasy, a potem posprawdzaj podstawowe elementy: * czy obiekt jest obiektem; * czy funkcja jest funkcją. Dzięki temu dowiedziesz swoich umiejętności testowania. ## Stwórz atrapy Atrapa (mock) to obiekt tworzony w celu zastąpienia zależności jednostki, którą testujesz. Jeżeli na przykład testujesz funkcję `saveBlogPost`, będzie Ci zależeć na przejęciu żądania HTTP, zanim zostanie ono wysłane przez funkcję. Będziesz chciał się dowiedzieć, przy pomocy czego Twoja funkcja wysyła żądanie, i zastąpić to atrapą. Korzystanie z atrap powinno być proste, jeżeli budujesz kod, korzystając ze wstrzykiwania zależności. ![Image description](https://cdn.hashnode.com/res/hashnode/image/upload/v1651040377614/YLtOIBH6Y.jpeg) ## Utrzymuj porządek Jak widzisz, w każdym teście dużo się dzieje. Możemy wyodrębnić trzy fazy całego procesu: 1. tworzenie atrap; 2. uruchamianie kodu do sprawdzenia; 3. sprawdzanie oczekiwań. Zachowanie tego podziału w kodzie ma sens: dzięki temu łatwiej będzie go czytać. Prostym sposobem na jego organizację jest zebranie wszystkich linii razem i dodanie komentarza określającego, jaka to część kodu. ## Programuj w oparciu o testy – test-driven development Programowanie oparte na testach to często spotykane podejście pozwalające na tworzenie schludnie wyglądającego kodu z dobrym pokryciem testami. Zaczynasz od dodania testu do funkcji, zanim zostanie ona wprowadzona. Uruchamiasz testy, które powinny dać wynik negatywny – jeśli tak się nie stanie, będzie to oznaczać, że coś jest bardzo nie tak: Twoim zadaniem będzie zbadać co. Natomiast po uzyskaniu w teście wyniku negatywnego dodaj do kodu brakującą implementację. Zgodnie z założeniami problem zostanie naprawiony. Jeśli wszystko pójdzie zgodnie z planem, będzie to inwestycja w ulepszenie Twojego rozwiązania – zarówno po stronie kodu, jak i testu – bez zmieniania logiki. Pozwoli Ci to na szybką [iterację](https://poznaj.dev/jak-zajsc-daleko-stawiajac-male-kroki) procesu budowania kodu i tworzenia do niego testów. Praktykowanie takiego podejścia powinno zagwarantować regularne pisanie testów do logiki. W tej sytuacji nie odczuwacz pokusy, żeby ominąć krok obejmujący pisanie testów – a dzieje się tak często, kiedy przesuwasz ich tworzenie na koniec sprintu. ![Image description](https://cdn.hashnode.com/res/hashnode/image/upload/v1651040379580/RLWmqctES.jpeg) ### Wyjątki od reguły Aby gdzieś dotrzeć, musisz wiedzieć, dokąd idziesz. Jeżeli chcesz rozeznać się w tym, jakie rozwiązania są wykonalne, daj sobie na chwilę spokój z testami. Po rekonesansie albo je dodaj, albo podejdź do problemu jeszcze raz, tym razem opierając się na testach. ## Brakujące testy Możesz mieć pecha i pracować na przestarzałym kodzie bez testów i innych środków kontroli jakości – czyli na przykład [na czymś takim](https://poznaj.dev/jak-zarzadzac-delikatnym-przestarzalym-kodem). W takim wypadku lepiej zastosować się do powiedzenia „lepiej późno niż wcale”: pracując nad bazą kodu, pisz jednocześnie testy. Idąc tą drogą, poprawisz sytuację na przyszłość, a może nawet znajdziesz podstępny bug ukryty gdzieś na rubieżach przypadków brzegowych. ## A co z Tobą? Jak trudna jest dla Ciebie nauka testowania? W Internecie można spotkać się ze skargami ludzi, którzy mają problemy ze znalezieniem dobrych materiałów dydaktycznych. Daj mi znać, jak to dotychczas wyglądało u Ciebie.