Czym są testy jednostkowe?

Cześć, w związku z większym zainteresowaniem bardziej technicznymi aspektami branży testerskiej, postanowiłem wam teraz wrzucić kilka artykułów dających realną wiedzę. Zaczynamy od odpowiedzi na jedno z pytań rozmowy kwalifikacyjnej na testera oprogramowania „Czym są testy jednostkowe?“. Pytanie to pojawia się na rozmowach i warto znać na nie odpowiedź, nawet jeśli same testy zwykle pisane są i uruchamiane przez programistę.

Na testy jednostkowe w kontekście pracy testera patrzy się dwojako. Z punktu widzenia testera o krótkim stażu pracy, zwłaszcza projektowym, Unit testy są rzeczą mocno teoretyczną, niedotyczącą nas testerów w żaden sposób. Zwykle wiedza zamyka się w tym, że wiemy, że testy jednostkowe są ważne i pisane są (zazwyczaj) przez programistów. Z kolei tester z większym doświadczeniem, który spotkał się lub otarł o brak takowych testów w projekcie, powie, że są one ważne i ułatwiają naszą testerów pracę.

Dobra, ale od początku, bo to tylko wstęp.

Czym w ogóle są testy jednostkowe lub unit testy?

Test jednostkowy (ang. unit test) – metoda testowania tworzonego oprogramowania poprzez wykonywanie testów weryfikujących poprawność działania pojedynczych elementów (jednostek) programu – np. metod lub obiektów w programowaniu obiektowym lub procedur w programowaniu proceduralnym. Testowany fragment programu poddawany jest testowi, który wykonuje go i porównuje wynik (np. zwrócone wartości, stan obiektu, zgłoszone wyjątki) z oczekiwanymi wynikami – tak pozytywnymi, jak i negatywnymi (niepowodzenie działania kodu w określonych sytuacjach również może podlegać testowaniu).

Źródło Wikipedia

Testy te pisane są głównie przez programistów i stanowią wówczas jeden z elementów wytwarzania oprogramowania. Czyli dopisując nową funkcjonalność w kodzie, programista pokrywa ją unit testami, by sprawdzić, czy ten pojedynczy element zachowuje się tak, jak powinien dla podanych danych. Testy te nie obejmują sprawdzenia, czy dodany element prawidłowo pracuje (integruje się) z pozostałymi elementami aplikacji.

Testy jednostkowe tworzone są w czasie kodowania aplikacji przez developerów. Teraz już wiecie, dlaczego zwłaszcza na początku naszej kariery możemy pomyśleć, że to nas nie dotyczy – w końcu to programiści mają się nimi zająć.

Ok to po co nam wiedza o testach jednostkowych? Czy jest to tylko jeden z elementów rozmów rekrutacyjnych? Czy też faktycznie wykorzystujemy ją jakoś w trakcie naszej testerskiej pracy?

Zdecydowanie jest to praktyczny aspekt pracy testera. Przede wszystkim musimy zdawać sobie sprawę, co może spowodować brak Unit testów w projekcie – moje doświadczenia pokazują, że projekty bez pisanych testów jednostkowych generują znacznie więcej defektów niż te, które takowe testy mają napisane. Wychwycenie błędów przez testy jednostkowe daje oszczędności w budżecie projektu.

Testy jednostkowe są u podstaw testów, po nich wykonywane są testy integracyjne, systemowe, a następnie testy akceptacyjne.

Czy testy automatyczne napisane w Selenium to to samo co Unit Testy?

W zasadzie Unit testy tak jak i testy są testami automatycznymi. Główną różnicą, natomiast jest tu moment ich wywołania.

Ostatnio usłyszałem „No dobra, ale jak nie mamy testów jednostkowych, to może, chociaż Selenium i niech nam automaty weryfikują GUI”. Uważam, że zastąpienie unit testów testami automatycznymi nie jest dobre. Przede wszystkim musicie zdać sobie sprawę z tego, że testy jednostkowe uruchamiane są znacznie wcześniej niż testów automatyczne na GUI, co za tym idzie, wychwytują błędy znacznie wcześniej. Jeśli…

No właśnie jeśli są poprawnie napisane. Dostałem bardzo cenną uwagę po opublikowaniu tego artykułu, że tak naprawdę czasami te testy są pisane tylko po to żeby odhaczyć nielubianą przez programistów czynność z listy Definition of Done. Kolejną różnicą jest to, że UT przeważnie są pisane na Mockach co też może wpływać na otrzymywane wyniki tych testów. 

Testy jednostkowe weryfikują kod i sprawdzają, czy działa on zgodnie z założeniami, jeżeli nie, to jeszcze przed oddaniem aplikacji do testów programista dostaje odpowiedź, że coś poszło nie tak i może na wcześniejszym etapie poprawić niedziałający kod.

Testy automatyczne są uruchamiane w momencie, gdy aplikacja jest wystawiona do testów. Czyli aplikacja ma GUI i jest gotowa do takowych testów. Testy te oczywiście dadzą odpowiedź, że dana funkcjonalność nie działa, tylko w mojej ocenie informacja o tym przyjdzie późno. Zwiększa to koszt poprawek i testów w danej funkcjonalności. Wydłużyć może również czas testów. Przykładowo w pierwszej iteracji testów znalezione zostaną tylko podstawowe błędy widoczne od razu, natomiast dokładniejsza weryfikacja funkcjonalności nastąpi dopiero przy ponownym wystawieniu aplikacji na testy. Również przez brak unit testów dopiero po wgraniu aplikacji na środowisko będziemy mieli ponowną weryfikację, czy wszystko dobrze działa.

Tak na koniec dorzucę, że testy jednostkowe są również pisane przez testerów, natomiast ciężko jest mi się wypowiedzieć czy to ma sens – może osoby, które się tym zajmują, napiszą coś więcej pod wpisem :).

Mówiąc „ma to sens” mam na myśli coś więcej niż stwierdzenie „Lepiej mieć jakiekolwiek testy niż nie mieć ich wcale”.