Co to jest code coverage i co nam mówi (a czego nie)?
Code coverage to metryka, która informuje, jaki procent linii (lub gałęzi, instrukcji) kodu został wykonany podczas uruchamiania testów. Przykładowo, jeśli funkcja ma 10 linii, a testy wywołują 8 z nich, pokrycie wynosi 80%. Brzmi to prosto i użytecznie. Problem w tym, że sama informacja o wykonaniu linii nic nie mówi o skuteczności ani jakości testów. Test może przecież uruchamiać kod bez żadnej weryfikacji wyniku, a mimo to podbijać statystyki pokrycia. Innymi słowy, 100% pokrycia nie gwarantuje absolutnie niczego pod względem jakości. Możesz mieć 100% pokrycie i jednocześnie kod pełen błędów. Wystarczy test, który wykonuje każdą linijkę, ale niczego nie sprawdza.
Dla zobrazowania: załóżmy, że masz funkcję ObliczRabat(cena, typUzytkownika). Piszesz test, który wywołuje ją z ceną 100 i typem użytkownika "PREMIUM". Wszystkie linie funkcji wykonują się, więc coverage wynosi 100%. Sęk w tym, że jeśli w teście zapomnisz o asercji sprawdzającej wynik, to taki test niczego nie weryfikuje. Nawet jeśli funkcja zwróci błędny wynik (albo kompletnie absurdalny, np. ujemny rabat czy tekst "kotek"), test przejdzie pomyślnie. Rezultat? Masz 100% pokrycia, ale zerową pewność, że kod działa poprawnie. Taki test oszukuje system i... samego siebie.
Mit 100% pokrycia = gwarancja jakości
Skoro 100% pokrycia kodu nie daje gwarancji bezbłędności, dlaczego w ogóle rozważa się taki cel? Często wynika to z mylenia pokrycia z jakością. Wysoki procent pokrycia cieszy oko, ale nie jest jednoznaczną miarą jakości. Pokrycie informuje jedynie, gdzie testy są, a nie czy są dobre. W praktyce można osiągnąć wysoki wynik, pisząc testy, które nic nie sprawdzają lub testując mało istotne scenariusze. Daje to fałszywe poczucie bezpieczeństwa. Liczba jest piękna, więc wydaje się, że wszystko gra, podczas gdy poważne błędy mogą czaić się w logice, której testy nie obejmują w sensowny sposób.
Drugi mit to przekonanie, że "więcej = lepiej". Owszem, dobrze jest mieć szeroki zestaw testów, ale ślepa pogoń za pokryciem może prowadzić do nieefektywnego wykorzystania czasu. Programiści zaczynają wtedy pisać testy pod metrykę, zamiast pod jakość. Przykład? Testowanie trywialnych akcesorów (getterów/setterów), byle tylko każda linia była uruchomiona. Sprawdzanie, czy GetName() zwraca imię ustawione chwilę wcześniej przez SetName(), ma znikomą wartość - to tak, jakby upewniać się, że woda jest mokra. Takie testy nie wykrywają realnych błędów, za to zwiększają objętość kodu, który trzeba utrzymywać.
Co więcej, osiągnięcie ostatnich kilku procent pokrycia bywa nieopłacalne. Zasada Pareto działa tu bezbłędnie, pierwsze 80–90% pokrycia uzyskujemy relatywnie łatwo, pokrywając kluczową logikę. Natomiast dobicie od, powiedzmy, 90% do 100% oznacza testowanie najbardziej błahych i najmniej ryzykownych fragmentów systemu. Koszt napisania i utrzymania tych rzadko przydatnych testów często przewyższa korzyści, jakie z nich płyną. W rzeczywistych projektach droga do 100% bywa wyboista: np. kod zależny od bazy danych czy zewnętrznych API wymaga pełnych testów integracyjnych i przygotowania środowiska, by pokryć wszystkie ścieżki wykonania. To dodatkowy wysiłek, który nie zawsze ma uzasadnienie biznesowe.
Jak mądrze korzystać z metryki pokrycia?
Skoro 100% nie jest magicznym wyznacznikiem jakości, to jak traktować code coverage? Najlepiej podejść do niego zdroworozsądkowo, jako narzędzia pomocniczego, a nie celu samego w sobie. W praktyce oznacza to:
• Używaj pokrycia jako wskazówki: Metryka pokrycia powie Ci, gdzie brakuje testów, ale nie powie, czy testy są dobre. Jeśli widzisz, że ważny moduł ma tylko 20% pokrycia, to sygnał, by tam zajrzeć i dopisać testy. Gdy inny moduł ma 90%, to dobrze, ale upewnij się, że stoją za tym sensowne scenariusze.
• Testuj to, co krytyczne: Priorytetem powinno być pokrycie testami kluczowej logiki biznesowej i przypadków brzegowych, zamiast dążenia do okrągłego numerka. Lepiej mieć 80% pokrycia przy naprawdę solidnych testach, niż 100% z testami pozorującymi sprawdzanie.
• Zachowaj kontekst: Każdy projekt jest inny. W systemach bezpieczeństwa czy lotniczych może celuje się w bardzo wysokie pokrycie, bo ryzyko błędu jest katastrofalne. W typowej aplikacji biznesowej sensowniej jest skupić się na obszarach największego ryzyka. Zakres testów powinien wynikać z ryzyka i potrzeb projektu, a nie z arbitralnie ustalonego procentu.
Przy okazji, jeżeli chcesz nauczyć się praktycznego podejścia do testowania w C#/.NET, rozważ udział w moim szkoleniu online Szkoła Testów Jednostkowych. Pokazuję tam krok po kroku, jak tworzyć skuteczne testy jednostkowe i integracyjne, które realnie podnoszą jakość aplikacji.
Podsumowanie
100% pokrycia kodu testami to bardziej mit niż wyznacznik jakości. Oczywiście, warto pisać testy i dbać o rozsądnie wysoki poziom pokrycia, ale liczba ta nie jest celem samym w sobie. Code coverage najlepiej traktować jako latarnię, wskazuje miejsca potencjalnie niedotestowane, ale nie jako miarę jakości. W dobrze przetestowanym projekcie ważniejsze od perfekcyjnego wyniku na wykresie są realne scenariusze pokryte testami i pewność, że kluczowe funkcjonalności działają zgodnie z oczekiwaniami. Koniec końców, lepiej mieć 85% pokrycia i spać spokojnie, niż na siłę dobijać do 100%, żyjąc w iluzji bezpieczeństwa. Piszmy więc testy mądrze, dla jakości kodu, a nie dla statystyk.
