Code coverage to współczynnik obrazujący, jaka część naszego systemu została pokryta testami. Jego celem jest znalezienie w systemie miejsc, które wymagają dopisania testów. Nie należy go traktować jako wyznacznik jakości systemu informatycznego. To, że oprogramowanie jest pokryte w 90% testami, nie oznacza wcale, że jest lepsze od innego pokrytego w 40%. Powinniśmy jednak dążyć do wymarzonego 100% pokrycia.
Podoba mi się historyjka napisana przez Alberto Savoia na temat pokrycia kodu testami:
Testivus o pokryciu kodu testami
Pewnego ranka programista zapytał wielkiego mistrza:
– Jestem gotowy do napisania kilku testów jednostkowych. Jakie pokrycie kodu testami powinienem osiągnąć?
Wielki mistrz odpowiedział:
– Nie przejmuj się wynikiem pokrycia kodu testami, po prostu napisz dobre testy
Programista uśmiechnął się, skłonił i wyszedł.
***
Tego samego dnia, drugi programista zadał to samo pytanie.
Wielki mistrz wskazał naczynie z wrzącą wodą i powiedział:
– Ile ziaren ryżu powinienem wsypać do tego naczynia?
Programistka, patrząc zdziwiona odpowiedziała:
– Jak mogę stwierdzić? To zależy ot tego ile osób chcesz nakarmić, jak bardzo są głodne, jakie inne potrawy im podajesz, ile masz dostępnego ryży itd.
– Dokładnie – powiedział wielki mistrz.
Drugi programista uśmiechnął się, skłonił i wyszedł.
***
Pod koniec dnia przyszedł trzeci programista i zadał to samo pytanie związane z pokryciem kodu testami.
– Osiemdziesiąt procent nie mniej! – odparł mistrz surowym głosem, waląc pięścią w stół.
Trzeci programista uśmiechnął się, skłonił i wyszedł.
***
Po tej odpowiedzi, młody uczeń zbliżył się do wielkiego mistrza:
–Wielki mistrzu, dziś usłyszałem, jak odpowiadasz na to samo pytanie związane z pokryciem kodu testami trzema różnymi odpowiedziami. Dlaczego?
Wielki mistrz wstał z krzesła:
– Chodź, zabierz ze sobą świeżą herbatę, porozmawiamy o tym
Gdy napełnili swoje kubki gorącą zieloną herbatą, wielki mistrz zaczął opowiadać:
– Pierwszy programista jest nowy i dopiero zaczyna pracę z testami. Teraz ma dużo kodu i żadnych testów. Ma długą drogę do przebycia; skupienie się wyniku pokrycia kodu testami w tym momencie byłoby przygnębiające i zupełnie bezużyteczne. Lepiej jest przyzwyczaić się do pisania i uruchamiania testów. Później może się martwić o wynik pokrycia kodu testami. Z drugiej strony, drugi programista ma duże doświadczenie zarówno w programowaniu, jak i testowaniu. Kiedy odpowiedziałem, pytając ją, ile ziarenek ryżu powinienem włożyć do garnka, pomogłem jej zdać sobie sprawę z tego, że wymagana ilość testów zależy od wielu czynników, a ona zna te czynniki lepiej niż ja to przecież jej kod. Nie ma jednej, prostej odpowiedzi, a ona jest wystarczająco inteligentna, by poradzić sobie z prawdą i pracować z nią.
– Rozumiem – powiedział młody uczeń
– Ale jeśli nie ma jednej prostej odpowiedzi, dlaczego odpowiedziałeś trzeciemu programiście ‘Osiemdziesiąt procent nie mniej’?
Wielki mistrz zaśmiał się tak głośno, że jego brzuch unosił się w górę i w dół, był to dowód na to że pił więcej niż tylko zieloną herbatę.
– Trzeci programista chce tylko prostych odpowiedzi, nawet gdy ich nie ma… a i tak ich nie przestrzega.
Młody uczeń i siwowłosy wielki mistrz skończyli pić herbatę w kontemplacyjnej ciszy.
Źródła:
Mike Cohn, Succeeding with Agile: Software Development Using Scrum, Addison-Wesley Professional, 2009
Alberto Savoia, How much test coverage do you need? – The Testivus Answer, http://www.developertesting.com/archives/month200705/20070504-000425.html
Martin Fowler, TestCoverage, https://martinfowler.com/bliki/TestCoverage.html