Testy jednostkowe z Net Core (C#) ebook

I. Uwaga

Nazywam się Dariusz Gruca, jestem starszym programistą pracującym w sektorze medycznym. Zachęcam cię do odwiedzenia mojej strony internetowej www.DariuszGruca.pl

Znajdziesz tam bloga ze wpisami technologicznymi oraz recenzje wręcz obowiązkowych książek dla każdego programisty. W przyszłości planuję też tworzyć kursy w wersji wideo.

Kod zawarty w tej książce jest w formie zdjęcia. To kompromis, na który musiałem się zdecydować po testowaniu różnych rozwiązań na urządzeniach mobilnych.

Poświęć te parę chwil i naucz się pisać testy jednostkowe. Zapraszam.

II. Wstęp

Programy są dzisiaj wszędzie. Aplikacje potrafią wykonywać za nas żmudne nudne operacje, przyśpieszając naszą pracę. Uczą nasze dzieci, dostarczają nam rozrywki. Prawdopodobnie nie istnieje już żaden aspekt życia człowieka, który nie byłby wspierany przez oprogramowanie. Komputer wykonuje instrukcja po instrukcji, wszystko to, co zostało mu polecone przez programistę. Więc to na naszych barkach spoczywa odpowiedzialność za jakość dostarczonego kodu. Błędy mogą być błahe, ale mogą również spowodować utratę milionów złotych lub co gorsza, przyczynić się do śmierci ludzi.

Pracuję nad systemem wspierającym laboratoria patomorfologiczne. W tego typu placówkach ocenia się czy badana osoba ma raka. Nie muszę więc chyba wspominać, jak ważna jest jakość takiego systemu. Błąd może zagrozić zdrowiu, a nawet życiu pacjenta.

Jednak każdy program powinien być odpowiednio przetestowany. Nie tylko te, które wpływają na ludzkie życie, czy finanse. Nawet proste oprogramowanie codziennego użytku powinno być wolne od błędów.

Moim zdaniem każdy programista, przed przekazaniem kodu do repozytorium, zobowiązany jest dobrze go sprawdzić. Ręczne wykonywanie tej czynności jest bardzo czasochłonne, a w niektórych przypadkach wręcz niemożliwe. Rozwiązaniem tego problemu są testy automatyczne, których fundament stanowią testy jednostkowe. W tej książce pokażę ci, jak szybko rozpocząć swoją przygodę z testami jednostkowymi. Ekspresowo nauczysz się pisać kod, który testuje kod.

III. Standard

Testy automatyczne stają się standardem. Coraz więcej firm wymaga tej wiedzy od swoich pracowników. Nie pozostań w tyle. Wiedza oraz umiejętności związane z tą tematyką z pewnością powinny być integralną częścią warsztatu każdego profesjonalnego programisty.

Coraz częściej w ogłoszeniach o pracę widnieje zapis o doświadczeniu komercyjnym, związanym z pisaniem testów automatycznych. Sięgając po tę książkę, zakładam, że ta tematyka jest dla ciebie nowa.

Jeżeli pracujesz jako programista, masz szczęście, możesz jeszcze dziś zacząć zdobywać doświadczenie komercyjne, pisząc testy jednostkowe w swoim obecnym projekcie. Teoria jest potrzebna, ale doświadczenie jest cenniejsze. Dlatego jak najszybciej wykorzystaj przekazaną przeze mnie wiedzę. Twoje pierwsze testy z pewnością nie będą idealne, nie martw się tym, z czasem będziesz w tym coraz lepszy. Ważne jest, abyś rozpoczął tworzenie u siebie nowego nawyku.

W przypadku, gdy dopiero poszukujesz swojej pierwszej pracy, możesz zabłysnąć dodatkową umiejętnością. Stwórz popisowy projekt, w którym pochwalisz się swoją wiedzą. Koniecznie napisz do niego testy. Zamieść projekt na https://github.com/ lub innym portalu, znajdź seniora (np. na https://www.linkedin.com/), daj mu swój projekt do code review, zastosuj się do jego sugestii i popraw swój kod. Pamiętaj, że projekt nie musi być kompletny. Chodzi o to, byś zaprezentował swoje umiejętności związane z tym, jak piszesz, jakiego używasz nazewnictwa, jak tworzysz architekturę rozwiązania. Wpisz link do swojego CV. Popisowy projekt z testami znacząco zwiększy twoją szansę na przejście do kolejnego etapu rekrutacji. Uwierz, niewiele osób ma takie projekty, a programista najlepiej ocenia innego programistę po jego kodzie. Tylko bądź uczciwy, code review to nie to samo co zlecenie komuś takiego projektu. Oszustwo bardzo szybko wyjdzie podczas rozmowy rekrutacyjnej, naprawdę nie warto kombinować. Świat jest mały i swoim nieczystym zagraniem możesz znacząco utrudnić sobie znalezienie pracy w tym zawodzie.

IV. Praca bez testów automatycznych

Wyobraź sobie następującą sytuację. Janusz uważa się za profesjonalnego programistę, przez co testuje swoje rozwiązanie przed wrzuceniem kodu do repozytorium, jednak testy wykonuje manualnie. Dostał on nowe zadanie do wykonania. Z uśmiechem na twarzy napisał piękny i czysty kod. Teraz chce sprawdzić, jak on działa. Uruchamia więc system, loguje się, wybiera z menu interesujący go moduł, następnie wprowadza dane, po czym okazuje się, że pojawił się błąd. Janusz poprawia więc kod i ponawia próbę. Tym razem problemem są dane, których nie może wykorzystać ponownie. Na twarzy Janusza pojawia się grymas, ponieważ musi teraz poświęcić czas, aby je wygenerować. Po kilku minutach klikania po różnych modułach zaczyna pojawiać się u niego frustracja. Kawa, na którą Janusz miał się udać po wykonaniu zadania będzie zbędna. Gdy w końcu udało mu się przygotować wszystko, co potrzeba, sprawdza swoją funkcjonalność. Na ekranie widzi błąd. Poprawia kod i proces zaczyna się na nowo. Horror. Czas nieubłaganie brnie do przodu. Nerwy przebijają się przez tamę, jego stoickiego spokoju zalewając go negatywnymi emocjami. Po siódmej porażce siarczyście klnie pod nosem. Musi wyjść na papierosa, by się uspokoić. Pali od niedawna, biedak nie potrafił w inny sposób poradzić sobie z szarpiącymi go nerwami. W pięknym ogrodzie jego umysłu niczym chwasty zaczynają pojawiać się myśli o zrzuceniu odpowiedzialności za jakość swojej pracy na testera manualnego.

Mija miesiąc, Janusz ma już dość i postanawia porzucić sprawdzanie jakości własnej pracy. Bez testowania, wrzuca zmiany do repozytorium. Z uśmiechem na twarzy przechodzi do tworzenia kolejnych zadań. Czuje złudną ulgę. Wydaje mu się, że niesamowicie przyśpieszył.

Niestety jego pozorne szczęście trwało tylko chwilę. Gdy pewny siebie był w połowie tworzenia nowego modułu, przyszedł czas zapłaty za dług, który niewątpliwie zaciągnął. Tester zaczął zgłaszać błędy do kodu, od którego rozpoczął swoje radosne kodowanie bez sprawdzania jakości. Janusz wrócił do poprzedniego zadania. Poprawa błędu okazała się prosta. Jednak przez to, że pętla zwrotna informacji o problemie występującym w kodzie wydłużyła się, poświęcił on dużo czasu na przypomnienie sobie, o co chodziło w danej funkcjonalności. Z dnia na dzień coraz więcej czasu poświęcał na analizę i poprawę błędów niż na tworzenie nowych funkcji systemu.

Tempo pracy zwolniło, było jeszcze gorzej niż podczas ręcznego sprawdzania kodu. Powrót do kontekstu poprzednich zadań zabierał Januszowi dużo czasu, co go frustrowało. Każdy zgłoszony błąd wpływał negatywnie na jego samopoczucie. Kiedyś czuł się profesjonalistą, teraz za każdym razem, gdy widział, zbliżającego się do jego biurka testera klął pod nosem. Stracił ten błysk w oku i zapał do pracy. Do pokonania negatywnych emocji nie wystarczały mu już papierosy. Co następnie, alkohol?

A mógł tego wszystkiego uniknąć, wystarczyło, żeby nauczył się pisać testy jednostkowe.

V. Poziomy pętli informacji zwrotnej

Człowiek popełnia błędy. Dlatego w pracę programisty wpleciona jest pętla informacji zwrotnej — im jest krótsza, tym lepiej. Szybka informacja o występującym błędzie w algorytmie pozwala zaoszczędzić dużo czasu.

Pętle informacji zwrotnej można podzielić na następujące poziomy:

Poziom 0 — Testy jednostkowe

Poziom 1 — Testy automatyczne serwer buildów

Poziom 2 — Testy manualne, wykonywane przez programistę

Poziom 3 — Testy manualne, wykonywane przez testera

Poziom 4 — Produkcja

Rys. 1. Pętla

informacji

zwrotnej w stosunku do czasu.

Im więcej błędów zostanie wyeliminowanych, przez testy jednostkowe tym lepiej. Produkcja nie powinna zgłaszać żadnych problemów, jedynie sugestie zmian funkcjonalności. Zdaję sobie sprawę, że tak nie będzie, ponieważ w każdym systemie zdarzają się bugi. Twoim celem jest, by było ich jak najmniej.

Jeśli posiadasz zestawy przypadków testowych dla całego systemu i używasz ich w procesie Continuous Integration, to jako programista możesz zrezygnować z testów manualnych, zostawiając tę czynność testerowi. Jednak zawsze mile widziane jest choć podstawowe „przeklikanie” funkcjonalności

Niektóre z firm tak bardzo ufają testom automatycznym, że pomijają pracę testera i każdy commit po przejściu testów wbudowanych w build serwer, od razu jest wgrywany na produkcję. Ten proces nazywa się Continuous Delivery

VI. Jakość kodu

System pokryty testami automatycznymi pozwala na częstszą i prostszą refaktoryzacje. Posiadając testy, możesz bez obaw ulepszać swój kod. Po zmianach uruchamiasz tylko zestawy przypadków testowych, czyli pliki zawierające klasy z testami. Jeśli nie zobaczysz czerwonego koloru, to nowa wersja może zostać wprowadzona do repozytorium.

Kod produkcyjny musi mieć odpowiednią strukturę, by dało się do niego napisać testy jednostkowe. Przez to w niezamierzony sposób wymuszają one na programiście pisanie lepszego jakościowo kodu.

ZasadySOLID staną się twoimi najlepszymi przyjaciółmi. Pomijając je, szybko odkryjesz problemy podczas budowania zestawów przypadków testowych. W najgorszym razie możesz nawet stwierdzić, że do napisanego kodu nie da się stworzyć testów. Czasem tak się dzieje. Nic się nie martw, wystarczy zdobyta w tej książce wiedza oraz trochę doświadczenia i ten problem przestanie istnieć.

VII. Mniejsza ilość błędów

Pisząc testy, układasz scenariusze warte sprawdzenia. Skupiasz się nie tylko nad optymistycznymi ścieżkami, ale też nad prawdopodobnymi problemami z kodem. Na początku swojej przygody czas poświęcony na tę czynność może wydawać ci się zbyt długi. Jednak z rosnącym doświadczeniem wyrobisz w sobie szósty zmysł do wyszukiwania i natychmiastowego eliminowania słabych punktów kodu. Jest to niezwykle cenna umiejętność. Możesz ją wykorzystać nie tylko dla swojej pracy, ale również podczas code review.

Warto wyrobić w sobie nawyk krytycznego spoglądania na kod, dzięki temu zminimalizujesz ilość zgłaszanych bugów.

W przypadku gdy tester zgłosi błąd, piszesz test, który nie przechodzi, potem poprawiasz kod. Następnie uruchamiasz wszystkie testy. Zielony kolor, powinien oznaczać, że poprawka nie wpłynęła negatywnie na system, co pozwoli ci w nocy zasnąć spokojnym snem. Napisany test jest gwarancją, że ten sam błąd już nigdy się nie pojawi w systemie.

Z własnego doświadczenia wiem, że testy jednostkowe