Bezwzględne testowanie

O testach modułowych pisałem już wcześniej, tak jak i o DevDay, ale wykład Grega Younga wzbudził u mnie pewien rezonans. Ten sam wykład z innej konferencji można obejrzeć np. tutaj. Polecam wszystkim chętnym.

Greg Young otworzył mi oczy na zupełnie nowe spojrzenie na testowanie programów. Od pewnego czasu miałem wrażenie, że napisanie dobrych testów nie jest łatwe i że jeszcze trudniej zmierzyć jakość testów, ale to były tylko przeczucia, a Greg pokazał, jak można do tego podejść w sposób bardzo ścisły i konsekwentny. Jednak nie to przykuło moją uwagę najbardziej.

Photo by kabils

Najciekawszą częścią wykładu była dla mnie część, w której autor postulował celowe zmiany w kodzie aby sprawdzić, czy testy się wysypią. Bingo! Dodałeś do zmiennej 'x' 1? A jeżeli zmienię zamienię 1 na 5, to co się stanie? Program ewidentnie się zmieni, ale czy te super-testy które napisałeś się wysypią? A jeżeli zamiast dodać odejmę, co wtedy? Kiedy o tym poważnie pomyśleć, to jest jedyny sposób sprawdzenia, czy testy działają. Gdybym miał czujnik przeciwpożarowy, który nie podniesie alarmu, kiedy przytknę do niego zapaloną zapałkę... nie czuł bym się do końca bezpiecznie. Najbardziej Greg zaimponował mi kiedy powiedział, że pracują nad narzędziem, które będzie wprowadzało takie zmiany automatycznie. Wow.

Później przyszła jeszcze jedna refleksja: ja już o tym gdzieś czytałem. Pragmatyczny programista, porada 64: "Użyj sabotażystów żeby testować swoje testy". Po raz kolejny okazuje się, że w informatyce wymyślono już multum dobrych idei, które tylko czekają na swój czas.

Dwa wnioski na dziś:

1. Koniecznie przeczytać jeszcze raz Pragmatycznego programistę.
2. Przydałby się post na temat tej książki i innych, które miały na mnie największy wpływ.

Testy modułowe albo mit pokrycia

Nie sądziłem, że ten post jest konieczny, ale wygląda na to, że dopadł mnie syndrom Blutfelda.

<dygresja>
Tych, którzy nie wiedzą, o co chodzi z Herr Blutfeldem, odsyłam do powieści Jacka Dukaja "Lód". W dużym skrócie Herr Blutfeld, jeden z drugoplanowych bohaterów wyżej wymienionej powieści, nie zabiera głosu w prawie żadnej dyskusji, których w opowieści jest naprawdę mnogo. W czasie, kiedy inni współpasażerowie Kolei Transsyberyjskiej spierają się żywo i efektownie, on woli oddawać się przyjemności jedzenia wszystkiego, co da się zjeść, od czego nabawił się paru dodatkowych podbródków.

Podczas jednego z postojów Herr Blutfeld nie wytrzymuje i wybucha. Okazuje się, że nie jest głupawy ani pozbawiony własnych poglądów - przeciwnie! Nie zgadza się z żadnym ze współpasażerów i uważa wszystkie ich opinie za głupie, nietrafione i kretyńskie. Problem w tym, że za każdym razem kiedy ma się już odezwać i wytknąć towarzyszom błędy w rozumowaniu, dochodzi do wniosku, że nie ma najmniejszego sensu się odzywać ponieważ wszystko, co ma do powiedzenia jest oczywiste! O-czy-wis-te! Nie ma sensu zużywać tlenu i drażnić neurony; tracić energię na tłumaczenie rzeczy tak prostych i po trzykroć oczywistych.

Podczas swojej przemowy nasz bohater ani na chwilę nie przestaje jeść. Priorytety!
</dygresja>

Przechodząc do rzeczy:
Ostatnio w rozmowie z dość kompetentnymi ludźmi usłyszałem taką opinię:

Nasze testy modułowe są dobre ponieważ mamy wysokie pokrycie kodu.

Photo by roxj

Na początku pomyślałem, że kolega sobie zażartował, ale ponieważ mój czujnik sarkazmu nawet nie drgnął, zapytałem czy oby na pewno nie raczył żartować... Niestety nie. Witki mi opadły. Gratulacje! Odkryliśmy pewną miarę jakości testów modułowych! Nie potrzebujemy o nich już żadnych książek, szkoleń ani dobrych praktyk! Wiemy już wszystko!


W dużym skrócie:
Dobre testy będą miały wysokie pokrycie kodu, ale wysokie pokrycie nie zagwarantuje nam, że testy są dobre. Dlaczego? Zastanówmy się, czym jest pokrycie kodu... to że linia kodu jest pokryta podczas testu oznacza, że w ramach wykonania testu ta linia została odwiedzona, nic więcej. Procesor przemielił instrukcje, które stały pod tą linią kodu. Nie ma tu mowy o sprawdzaniu, czy te instrukcje zrobiły to, czego się spodziewaliśmy. Nie ma nawet słowa o tym, czego się spodziewaliśmy.

Dobre testy dokładnie określają czego się spodziewamy, łącznie z tym, co się nie powinno wydarzyć... problem jest taki, że do tego opisu ciężko przypiąć liczbę.
Jest to zaleta, którą mierzenie pokrycia posiada i która jest niestety nadużywana.