Code coverage to miara pokrycia kodu testami. Innymi słowy: procentowy wskaźnik, jaka część naszego kodu jest “otestowana”. To narzędzie może nam posłużyć w rozpoznaniu na niższym poziomie projektów lub modułów, które obszary są zabezpieczone testami, a w których ich brakuje. Czasami też - niestety - jakieś wymogi formalne przetargu lub zamówienia mogą wymuszać określony poziom pokrycia testami. Napisałem niestety, bo pojedyncza liczba lub liczba per moduł/projekt, komuś z zewnątrz projektu niewiele powie. Chyba lepiej mieć pokryty testami kod biznesowy, kluczowy, a nie np. jakąś pomocniczą bibliotekę; tymczasem “gołe” liczby mogą sprawić, że jest to równoważne. Co więcej, można też oszukać narzędzie do code coverage pisząc testy… bez asercji: testy się nie wysypią, a na pewno uruchomią kod…
Wracając jednak do korzyści dla zespołu programistów, można skorzystać z code coverage zarówno w nowym, jak i istniejącym projekcie. Ta miara powinna być traktowana raczej “relatywnie”, trochę tak, jak “dług techniczny”, obliczany przez takie narzędzia jak Sonar. Chodzi o to, że pewnie trudno albo w ogóle bez niepotrzebnie byłoby po prostu dążyć do 100% pokrycia testami. Jednakże, jeśli w kolejnych iteracjach ten wskaźnik spada, to może oznaczać, że po prostu piszemy za mało testów (lub nie piszemy ich wcale) dla nowego kodu. A to byłoby bardzo złe. Podobnie z sytuacją istniejącego projektu - nawet jednorazowe uruchomienie code coverage na początku pozwala ocenić, jak dużo jest testów i jakiej są one “jakości”.
…