Po co nam testy jednostkowe, skoro mamy testerów?

by Sandra Wyzujak

Testy jednostkowe są dla początkujących programistów tematem niekiedy “mitycznym” – coś o nich słyszeli, ale podczas nauki podstaw mało kto o nich myśli. Zagadnienie to wraca w momencie poszukiwań pierwszej pracy. W wielu ofertach jest wzmianka o testowaniu, a doświadczeni koledzy twierdzą, że ich znajomość, to dla dobrego programisty podstawa.
Z drugiej strony firmy mają przecież testerów. Jest nawet podział na automatycznych i manualnych! Skoro do sprawdzania oprogramowania są oddzielne działy i stanowiska, to po co mamy poznawać frameworki i pisać setki linii kodu testującego przeznaczając na to rocznie dziesiątki godzin, czy nawet setki godzin?

Zacznijmy od zdefiniowania testu jednostkowego. Jest to metoda sprawdzająca, czy nasza implementacja działa prawidłowo. Sprawdzać powinniśmy pojedyncze elementy (jednostki) kodu. Jeden ze standardów nazywania testów opisał Roy Osherove w książce “Testy jednostkowe. Świat niezawodnych aplikacji.”. Wzór polega na podawaniu na początku informacji o tym co testujemy (np. nazwa metody), następnie po “_” opisujemy dane wejściowe i w ostatniej sekcji podajemy oczekiwany rezultat.

Przykładowy test jednostkowy (napisany przy użyciu frameworku NUnit) dla metody “GetSum” klasy “Calculator”, która przyjmuje 2 liczby całkowite jako parametry i zwraca ich sumę. W tym scenariuszu podajemy 2 liczby dodatnie i oczekujemy ich sumy jako zwrotu.
W innych scenariuszach moglibyśmy sprawdzać metodę np. dla liczb ujemnych.

Wiemy już czym jest test jednostkowy, jak nadawać mu nazwę oraz jak wygląda.
Nie zmienia to faktu, że przecież dla powyższego przykładu testerzy zauważyliby bez problemu błąd, a nawet sam programista powinien uruchamiając aplikację przed commitowaniem zmian sprawdzić kilka przypadków. Czy opłaca się w takim razie je tworzyć?


Odpowiedź brzmi: tak.


Po pierwsze – testy jednostkowe to oszczędność czasu programisty podczas implementacji. Po co za każdym razem uruchamiać aplikację (która w najlepszym przypadku otwiera się kilka sekund), jeśli możemy najpierw sprawdzić poprawność z poziomu kodu, co powinno trwać sekundy (maksymalnie minuty) dla tysięcy przypadków. W momencie, gdy wszystko będzie “na zielono” (wszystkie założenia w testach zostaną spełnione) możemy sprawdzić, czy aplikacja na pewno “wstaje” i nie uszkodziliśmy omyłkowo modułu, który był nietestowalny z poziomu kodu.
Proces ten możemy usprawnić stosując mechanizm “Live unit testing” (dostępny np. w wersji Enterprise środowiska Visual Studio), gdzie po zmianie kodu automatycznie testy z nim powiązane są uruchamiane.

Po drugie – mniej błędów zwracanych przez testerów, to oszczędność czasu po zamknięciu zadania. Na każdy błąd, który wyszedł na środowisko testowe zarówno osoba, która go znajduje, jak i programista muszą poświęcić czas. Jeśli testujemy jednostkowo wszystkie scenariusze, to szansa na zwrot zadania – który potrzebuje opisu co jest nie tak – spada.

Po trzecie – w łatwy sposób możemy sprawdzić, czy nie popełniamy ponownie starych błędów. Jeśli nasz kod nie działa prawidłowo powinniśmy dodać brakujące przypadki testowe. Nie dość, że pomogą nam w opracowaniu poprawki, to w przyszłości uchronią nas one przed powtórzeniem błędu, gdyż jeśli jakaś zmiana uszkodzi logikę zawartą w kodzie testy nas o tym poinformują.

Przykładowy wynik dla testu, którego warunki nie zostały spełnione.

Po czwarte – TDD (Test-driven development) – jest to metoda wytwarzania oprogramowania, w której najpierw piszemy testy, a później dopiero kod, który ma je spełnić. Osobiście jestem jej sympatykiem, często pomaga mi, gdy nie mam pomysłu od czego zacząć. Dzięki tworzeniu na początku testów łatwiej jest określić czego potrzebuję.
Technika TDD to oczywiście szersze zagadnienie, które wymagałoby oddzielnego wpisu.

Mam nadzieję, że powyższe przykłady jasno wykazały, że testy jednostkowe są nie tylko pomocą dla programisty, ale również zmniejszają ilość pracy innych zespołów. Dzięki temu możemy efektywniej dostarczać wolne od błędów oprogramowanie.


Krzysztof, C# Developer

Od zawsze planował zostać programistą, uwielbia testy jednostkowe. Poza pracą pasjonuje się językami i ekonomią. Jego ulubiony sposób spędzania czasu to granie w papierowe RPG i planszówki.