Testy automatyczne

Czy zawsze jest sens je stosować?

Piotr Wandycz
Dla juniorów

Junior developer na początku swojej drogi ma masę rzeczy do ogarnięcia, zaczynając od rozwiązania problemu “jak zrobić, żeby to się kompilowało?”, a kończąc na kontroli wersji. Jak ja szukałem pierwszej pracy to miałem już parę projektów do pokazania, ale technicznie to pisałem wszędzie voidy, bo nawet nie wiedziałem, że metody mogą coś zwracać. O to, co dzisiaj jest standardem – np. wstrzykiwanie zależności – dekadę temu nikt nie pytał na rozmowach kwalifikacyjnych na młodszego programistę (a przynajmniej nie na tych, w których brałem udział). Obecnie mogą padać pytania o testy, ale to czy ktoś je potrafi pisać, traktowałbym jako miły dodatek, a nie wymóg. Przyczyn jest kilka.

Co to są testy automatyczne oprogramowania?

Jeśli pierwszy raz spotykasz się z pojęciem testowania automatycznego – pozwól że wymyślę naprędce definicję. Test jednostkowy to kawałek kodu, wywołujący metodę, aby sprawdzić, czy działa ona poprawnie. Ma konkretne dane wejściowe, żeby rezultat był zawsze taki sam. Porównujemy czy wynik naszej funkcji jest taki, jak się spodziewaliśmy, i jeśli tak to test przechodzi, a jak nie to zwraca błąd. Najgłupszy przykład z kalkulatorem: dane wejściowe to 2 i 2, metoda “dodaj” i założenie, że wynik to 4. Dzięki wpisaniu parametrów na sztywno możemy uruchomić test milion razy i wynik zawsze będzie taki sam.

Zalet ma to co niemiara – dopisując nowe funkcjonalności w aplikacji, a wraz z nimi testy, w ciągu sekund jesteśmy w stanie sprawdzić, czy nic nieświadomie nie zepsuliśmy. Czy nagle tworząc metodę “odejmij”, testy naszej metody “dodaj” przestały przechodzić? Przecież 2+2 to powinno być 4, musieliśmy coś namieszać, robiąc zmiany. Poza testami jednostkowymi, sprawdzającymi jak zachowują się pojedyncze metody w izolowanym środowisku, istnieją też testy integracyjne – testujące zależności między modułami, a nawet testy akceptacyjne – walidujące czy wymaganie postawione przez klienta zostało zrealizowane. Testy automatyczne potrafią być naprawdę potężnym narzędziem, dlaczego więc nie wymagałbym ich od juniora?

Jak to wygląda w prawdziwej pracy?

Wujek Bob może sobie pisać o stuprocentowym pokryciu kodu testami, albo o 20 tysiącach testów jednostkowych w projekcie FitNesse. Jako właściciel tego projektu, czyli równocześnie jego klient, widocznie stwierdził, że ma na to budżet. Ja też otestowałem każdy feature w swoim projekcie na GitHubie jednostkowo i integracyjnie, mimo że to nie ma żadnego sensu. Chciałem po prostu zobaczyć czy utworzona przeze mnie architektura jest testowalna. Niestety pracując w małych firmach, nie widziałem żadnych testów automatycznych. W korpo mającym duży dział Microsoft znalazłem pojedyncze osoby piszące, bądź potrafiące pisać testy. Może to ja miałem pecha, a może taki jest stan faktyczny branży – nawet mimo pytań na rozmowach kwalifikacyjnych, po przyjściu do firmy testów nie widać.

Z testami jest pewien problem – pisanie testów to dodatkowa praca programisty, za którą musi zapłacić klient, oraz dodatkowa pula kodu, o który trzeba dbać. Dodatkowo masa projektów posiada taką konstrukcję, że patrzysz na to i nie wiesz, od której strony zabrać się do testowania. W teorii coś, co wydaje się banalne, w praktyce staje się niemożliwym. Jak będziesz umiał/-a pisać kod testowalny, to prawdopodobnie będzie on zgodny z SOLID i innymi dobrymi praktykami. Nauka wyjmowania logiki na zewnątrz i tworzenia prawidłowych testów jednostkowych może zająć lata. Zdarzają się też małe projekty 3-miesięczne, albo wyjątkowo CRUDowe. Czy jest sens pisania dla nich testów, zwłaszcza gdy logiki jest tam bardzo mało? Może wystarczyłoby pokryć nimi tylko te kilka ważnych klas? Czy warto robić testy integracyjne w pierwszym miesiącu nowego projektu, gdzie jego struktura może zmienić się kilkukrotnie?

Nie chciałbym, żebyś odniósł/odniosła wrażenie, że pisanie testów jest bez sensu. Ma dużo sensu, tylko trzeba wiedzieć kiedy, albo jak je stosować. W Internecie jest masa materiałów bezrefleksyjnie przedstawiająca tylko pozytywne strony i słowem niewspominająca o dodatkowych obowiązkach, jakie niesie ze sobą decyzja o wprowadzeniu testów do swojego procesu wytwarzania oprogramowania. Testy świetnie sprawdzają się podczas refaktoryzacji, jeśli wiemy, jaki jest rezultat danego fragmentu kodu, to po przepisaniu go wynik powinien pozostać ten sam. Pisanie dobrych testów to wielka sztuka i powinniśmy podchodzić do tego tematu ze szczególną uwagą, żeby nie przyniosły więcej szkód niż pożytku.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *