Scroll to top
en pl

Pokrycie testami


Mateusz Olczak - 24 października 2019 - 0 comments

Testowanie jest podstawą zaufania do funkcjonowania każdego programu – o tym nie trzeba nikogo przekonywać. Testy są potrzebne, jednak przygotowanie testów może wymagać odpowiedzi na wiele pytań. Jaki rodzaj testów powinniśmy wybrać? Ile powinno ich być? Które funkcje powinny zostać sprawdzone? 

Zgodnie z pierwszym prawem Murphy’ego – należy spodziewać się problemów nawet tam, gdzie ich wystąpienie jest zupełnie nieprawdopodobne. Zasada ta bardzo dobrze sprawdza się w procesie wytwarzania oprogramowania, bo jeśli istnieje choć cień szansy, że coś może się nie udać, to możemy mieć “pewność”, że tak się stanie. Pisząc program nie można zakładać, że użytkownicy nie wykonają czynności, która spowoduje crush. Należy wziąć pod uwagę różne przypadki: graniczne, brzegowe, podstawowe, losowe oraz tzw. corner case.

Wydawać się może, że większa liczba testów to większe bezpieczeństwo – w końcu jeżeli przetestujemy każdą ewentualność, możemy stwierdzić, że jesteśmy przygotowani na wszystko. Wbrew pozorom nie zawsze jest to zjawisko korzystne. Przyjrzyjmy się wadom i zaletom stuprocentowego pokrycia.

Pokrycie testami

Stopień pokrycia testami nie zawsze oznacza to samo. W zależności od zastosowanej metryki może to być wskaźnik pokrycia klas i traitów, indeks ryzyka zmian w kodzie (tzw. CRAP Index), liczba przetestowanych metod i funkcji lub pokrycie linii kodu. Ta ostatnia metryka jest najbardziej miarodajna, ponieważ obejmuje ona także rozgałęzienia kodu. 

Stuprocentowe pokrycie kodu testami może być zjawiskiem korzystnym. W przypadku takiego podejścia nabieramy pewności, że teoretycznie każde rozgałęzienie kody zostało sprawdzone, co przekłada się na większe zaufanie do aplikacji. Chęć osiągnięcia doskonałości, czyli 100% pokrycia testami, może być czynnikiem motywującym do tworzenia nowych testów. Poza tym taka statystyka jest niewątpliwym atutem każdej biznesowej prezentacji.

Dążenie do stuprocenowego pokrycia kodu ma również pewne wady, które w rzeczywistości pociągają za sobą więcej negatywnych konsekwencji niż pozytywnych. Całkowite pokrycie kodu testami sprawia, że programiści mają zbyt duże zaufanie do aplikacji. Są oni przeświadczeni, że testy chronią program przed każdym błędem, a to może wpłynąć na obniżenie jakości i poprawności tworzonego kodu. Często chęć osiągnięcia wysokich statystyk pokrycia jest przyczyną sztucznych modyfikacji kodu produkcyjnego – zmiany te wprowadzane są w celu pokrycia nietestowalnych fragmentów kodu. Dodatkowo motywacją do tworzenia kolejnych testów jednostkowych staje się zwiększenie pokrycia samo w sobie, a nie rzeczywista potrzeba przetestowania programu. W takim przypadku zespół traci czas na sprawdzanie kodu, który nie wymaga dokładnych testów jednostkowych, podczas gdy faktycznie czas ten powinien zostać przeznaczony na testy automatyczne i testy integracyjne.

Jak mierzyć pokrycie testami?

Pomimo różnicy w podejściu do stuprocentowego pokrycia testami jedno jest pewne – pomiar stopnia pokrycia kodu przynosi korzyść. W przypadku bardzo rozbudowanych programów ręczne sprawdzanie tych statystyk jest niemal niewykonalne i wymagałoby poświęcenia ogromnego nakładu czasu i pracy testerów i programistów. Z pomocą przychodzą narzędzia do pomiaru stopnia pokrycia kodu testami (np. JaCoCo, Cobertura, PHPUnit).

Darmowe narzędzie do pomiaru pokrycia kodu testami JaCoCo to najczęściej wykorzystywany tego typu plugin. Jego ogromną zaletą jest możliwość integracji z systemami Jenkins, Bamboo lub Maven. Poza tym JaCoCo pozwala na łatwe generowanie raportów.

Analiza raportów wygenerowanych przez narzędzie do pomiaru pokrycia kodu pozwala także na określenie, które klasy i ścieżki powinny zostać przetestowane. Dzięki pomiarom pokrycia można sprawdzić poprawność działania najważniejszych modułów systemu i stworzyć reguły automatycznego odrzucania pull requestów.

Zawsze należy pamiętać, że nawet stuprocentowe pokrycie kodu nie odzwierciedla faktycznej efektywności testów, gdyż jest to tylko jedna z metryk opisujących jakość kodu. Pisząc testy trzeba spojrzeć na program całościowo, ponieważ ważniejsze od liczby testów do pojedynczych metod jest przetestowanie złożonych funkcjonalności, które są podstawą prawidłowego działania aplikacji.

Related posts