Testy

O tym jak ważne są testy chyba nie muszę nikomu mówić, nie mniej jednak są sytuacje, kiedy testy dają nam fałszywe poczucie bezpieczeństwa. W jednym z projektów jakie miałem okazje realizować, klient podchodził do testów bardzo rygorystycznie. Podeście to, w pewnym momencie przekroczyło moim zdaniem granicę absurdu, kiedy to została zatrudniona osoba, specjalnie po to, ażeby pisała test. Testy post-factum do kodu, którego nie znała, rozwiązującego problemy, których nie rozumiała. Wartość tych testów była jak by to powiedzieć niezbyt wysoka. Klient był zadowolony, pokrycie kodu testami rosło. Zespól tworzył testy jakie uważał za konieczne, a dedykowany developer uzupełniał testy do magicznego wymaganego przez klienta poziomu pokrycia.

Błędne wyniki

O jakości testów przekonaliśmy się w momencie, w którym konieczne były zmiany. Jak wiadomo testy przy zmianach są ważne, gdyż pozwalają sprawdzić czy główne funkcje klas pozostają niezmienione. Tutaj zetknęliśmy się z jednym z błędnych wyników.

Testy – False Positive

Fałszywie pozytywne testy, są szczególnie niebezpieczne według mnie, gdyż dają złudne poczucie bezpieczeństwa. Bezpieczeństwa, które przy zmianach jest jakże ważne. Zmieniamy coś, uruchamiamy testy, sprawdzamy podstawową ścieżkę wykonania – działa, działa. Niestety zmiany nie były takie niewinne. Z powodów braku wiedzy o warunkach brzegowych testy pokrywały całą klasę, ale specyficzne przypadki nie były testowane, o czym ów piszący testy developer nie wiedział (tak, tak daliśmy ciała nie pisząc tych testów wcześniej).  Problem na szczęście wyszedł w czasie testów manualnych. Cała ta sytuacja zapaliła u nas światełko ostrzegawcze i zmusiła cały zespól do refleksji, na temat jakości testów oraz baczniejszego zwracania na nie uwagi.

Testy – False Negative

Ten przypadek testów jest mniej niebezpieczny od opisanego wcześniej “False Positive”, jest on jednak dużo bardziej denerwujący. Odnosi się do przypadku, w którym, mimo iż implementacja jest prawidłowa testy failują. Odruchowo sprawdzamy co może być nie tak i szukamy w pierwszej kolejności problemów w zmienionym kodzie, a dopiero później w implementacji testów. Warto dodać, iż tego typu problemy występują szczególnie często po znalezieniu błędów w implementacji, gdzie pierwszą rzeczą powinno być poprawienie (bądź dodanie nowych) testów, na takie, ażeby błąd został odkryty w testach, a następnie poprawiona implementacja. Może to dać nam fałszywie negatywne wyniki testów w przypadkach, o których nie pomyśleliśmy w czasie poprawek. Nie ważne jak znaleźliśmy takie testy, poprawka w takich przypadkach powinna zostać starannie przemyślana i wykonana z rozwagą tak, ażebyśmy nie stali się ofiarami testów fałszywie pozytywnych.

Podsumowanie

Nie jestem specjalistą od testów. Jednakże w czasie pracy spotkałem się z różnymi przypadkami, gdzie testy ratowały nam skórę, jak i takie, gdzie zepsuły nam naprawdę wiele krwi. Zwracajmy uwagę na nasze testy i w miarę możliwości starajmy się być świadomymi wszelkich zagrożeń. A co najważniejsze, jeśli mamy wiedzę o warunkach specjalnych, które mogą być ciężkie do wyłapania piszmy testy, w których będą one specjalnie, może nawet nadmiarowo testowane. Pozwoli nam to uniknąć późniejszych problemów.