Po wygenerowaniu raportu pokrycia kodu z użyciem PHPUnit i Xdebug/PCOV, czas na najważniejsze: jego analizę. Sam raport to tylko zbiór danych – dopiero ich interpretacja pozwala zrozumieć, co w naszym kodzie wymaga dodatkowych testów, które fragmenty są ryzykowne, a które są pokryte, ale pozornie. W tym artykule pokażę Ci dokładnie, jak czytać raport HTML, jak rozpoznawać potencjalne problemy i jak wykorzystać pokrycie do strategicznego ulepszania testów.
Raport HTML – pierwsze spojrzenie
Po uruchomieniu testów z flagą --coverage-html, PHPUnit tworzy katalog (np. coverage-report/), w którym znajdziesz plik index.html. To punkt wejścia do raportu.
Na górze zobaczysz podsumowanie: całkowite pokrycie linii, pokrycie gałęzi oraz średni wskaźnik CRAP. Poniżej znajduje się lista plików i klas posortowanych alfabetycznie, z kolorowymi wskaźnikami i wartościami procentowymi.
Kolory mają znaczenie:
- Zielony – kod pokryty testami.
- Czerwony – kod niepokryty.
- Żółty – kod częściowo pokryty (np. tylko jedna gałąź
if).
Klikając nazwę pliku, przechodzisz do widoku jego zawartości, gdzie każda linia jest oznaczona odpowiednim kolorem.
Analiza klasy i metody – na co patrzeć?
- Metody 100% pokryte – świetnie! Ale sprawdź, czy testy zawierają asercje i testują wszystkie przypadki logiczne.
- Metody częściowo pokryte – żółty kolor oznacza, że np.
ifzostał wykonany tylko w jednym wariancie. Sprawdź, czego brakuje. - Metody czerwone – nie były uruchomione przez żaden test. Czy są ważne? Czy zawierają logikę biznesową? Czy może są martwym kodem?
- Złożone metody z wysokim CRAP-indexem – to miejsca szczególnie podatne na błędy. Ich testowanie powinno być priorytetem.
Wskaźnik CRAP – co oznacza i jak go czytać?
CRAP (Change Risk Anti-Patterns) to wskaźnik ryzyka zmian danej funkcji. Im wyższy, tym bardziej złożona funkcja, a im niższe pokrycie, tym większe ryzyko wprowadzania błędów przy modyfikacji.
Formuła CRAP:
CRAP(m) = comp(m)^2 * (1 - cov(m))^3 + comp(m)Gdzie:
comp(m)to złożoność cyklomatyczna metody,cov(m)to pokrycie kodu wyrażone jako liczba z przedziału 0–1.
Interpretacja:
- CRAP < 15 – niskie ryzyko,
- 15–30 – średnie,
-
30 – wysokie ryzyko, warto napisać dodatkowe testy lub rozbić metodę na mniejsze.
Strategia poprawy pokrycia
Pokrycie nie jest celem samym w sobie. Celem jest świadome pokrycie — testowanie tych fragmentów kodu, które:
- zawierają logikę biznesową,
- wykonują obliczenia,
- decydują o przebiegu aplikacji (np. routery, kontrolery, walidatory).
Nie trać czasu na testowanie getterów, setterów, DTO, kodu pomocniczego bez logiki. Skoncentruj się na:
- Testach ścieżek warunkowych (if/else/switch)
- Testach wyjątków (czy kod rzuca wyjątek w odpowiednich warunkach)
- Testach błędnych danych wejściowych
- Testach edge-case'ów (puste kolekcje, null, liczby ujemne, puste ciągi)
Dla kodu o wysokim CRAP, warto rozważyć:
- refaktoryzację (rozbicie metody na mniejsze)
- zastosowanie wzorców (np. strategia, komenda, walidator)
- delegowanie złożonej logiki do osobnych klas (np. serwisów)
Najczęstsze pułapki w interpretacji
- 100% pokrycia, ale brak testów logicznych – testy mogą wykonywać linie, ale nie zawierać asercji.
- Wysokie pokrycie, ale brak pokrycia gałęzi – np. test wykonuje metodę, ale nie pokrywa wszystkich
if/else. - Niskie pokrycie plików nieużywanych – może oznaczać martwy kod, który warto usunąć.
- Zawyżone pokrycie przez bootstrapy lub generatory kodu – np. testy Laravel mogą wykonywać wiele linii frameworka, ale nie testują Twojego kodu.
Narzędzia wspierające analizę
Jeśli pracujesz nad większym projektem, warto sięgnąć po dodatkowe narzędzia:
- Infection – testy mutacyjne; sprawdzają, czy testy wykrywają zmiany w kodzie.
- phpmetrics – pokazuje złożoność, zależności, coupling i koreluje je z pokryciem.
- SonarQube – daje kompleksowy przegląd jakości kodu (łącznie z pokryciem, błędami i konwencją).
Wnioski i dobre praktyki
- Raport pokrycia to nie wyrocznia – to narzędzie pomocnicze, które trzeba czytać w kontekście.
- Najważniejsze to zrozumienie, które funkcje są krytyczne i wymagają testów.
- CRAP index i pokrycie gałęzi to potężne wskaźniki, które prowadzą do realnej poprawy jakości.
Dobrze wykorzystany raport pokrycia kodu pozwala zidentyfikować słabe punkty aplikacji, zaplanować testy uzupełniające i zwiększyć zaufanie do refaktoryzacji. To nie tylko liczby i kolory — to mapa jakości Twojego kodu.