110% pokrycia kodu
Cóż, zdarzają się ludzie, którzy wierzą, że pokrycie testami 100% kodu wystarczy,
aby stwierdzić, że w projekcie są prawidłowe testy.
Osiągnięcie takiego wyniku przy niebanalnym projekcie jest sprawą niełatwą
i czapki z głów przed tymi, którzy to osiągną, ale jednak pokrycie testami kodu mierzy
nic innego niż, cóż, pokrycie testami kodu…
Jeśli ktoś uważa, że pokrycie testami 100% kodu to wszystko co jest potrzebne,
to jest w sporym błędzie. To, że masz pewność, że wykonana została każda linijka
kodu, nie oznacza w ogóle, że kod spełnia wymagania i że zadziała w każdej
z przewidzianych w projekcie sytuacji. Pomijając już kwestie testowania rozmaitych
zakresów parametrów wejściowych lub interakcji z innymi częściami systemu,
może też zdarzyć się, że testami pokryty jest też kod, który w ogóle nie jest potrzebny.
Przytrafiło mi się, że przeglądałem pewien kawałek kodu i po jakimś czasie doszedłem
do wniosku, że część z tego kodu nie jest potrzebna, po prostu tego kodu nie powinno
w ogóle być. Nie robił niczego złego w tym sensie, że projektowana funkcjonalność
była realizowana, a od strony pokrycia kodu wszystko było w porządku, kod wykonywał
się. Szkopuł jednak w tym, że sporo linijek mogłem spokojnie usunąć i funkcjonalność
była nadal zachowana. Miałem więc zmierzone pokrycie kodu, który nie powinien
istnieć. Po pewnym czasie wyszło też, że kod ten wykonywał 4 niepotrzebne SELECT-y,
więc de facto był bugiem. A bugi się ubija 
.
Wynikają z tego przynajmniej dwie kwestie
- mierzenie pokrycia kodu to jeszcze nie wszystko co można zrobić
- przeglądy kodu to bardzo dobra rzecz
