Znów o testach jednostkowych
2008-12-18 21:04Poprzednia notka o “rootkitach i innych nieszczęściach” zdołała utrzymać się długo, więc mogła stworzyć wrażenie, że cały czas źle się u mnie dzieje :) Nieprawda to oczywiście, więc wypadałoby w końcu coś na tę dezinformację poradzić.
Ostatnio cierpię na niewielki brak czasu spowodowany koniecznością dokładania nieco poważniejszych wysiłków co do pewnego dzieła, które docelowo ma zapewnić mi otrzymanie tytułu inżyniera informatyki. Z pewnych względów nie zdradzę, czym ono jest, ale pozwolę sobie wspomnieć o pewnych wnioskach, które przy okazji mi się nasunęły.
Parę miesięcy temu wypowiadałem się pochlebnie na temat testów jednostkowych, mając wtedy raczej niezbyt duże doświadczenie w ich stosowaniu. Dzisiaj jest już ono zdecydowanie większe i w związku z tym stwierdzić muszę, że… Nie, nie chcę powiedzieć, że wtedy myliłem się całkowicie ;P Chodzi raczej o równowagę zalet i wad.
To prawda, że unittesty dobrze sprawdzają się jako narzędzie znajdowania błędów i zapobiegania im. Do pewnego stopnia pomagają też w poprawianiu interfejsu tworzonych klas, tak aby ich użycie było wygodniejsze i bardziej intuicyjne. Te korzyści mają jednak swoją cenę, którą jest przede wszystkim czas poświęcony na pisanie owych testów – zwłaszcza w niektórych metodykach wytwarzania oprogramowania, które kładą na nie ogromny nacisk. Całkiem normalna jest bowiem sytuacja, że kod testowy jest dłuższy niż testowany (czasem nawet kilkakrotnie). Dodatkowo nie mamy przecież znikąd żadnej gwarancji, że ów testowy kod sam nie zawiera jakichś błędów… W sumie więc dochodzi nam sporo dodatkowej pracy w zamian za większą niezawodność tworzonego oprogramowania.
Drugi wniosek jest bardziej – że tak powiem – filozoficzny :) Otóż programowanie wedle zasady:
- while (!ProgramGotowy())
- {
- NapiszTest();
- do
- {
- NapiszLubPoprawKod();
- UruchomTest();
- } while (!TestPrzeszedl());
- }
może i jest efektywne, ale na dłuższą metę zaczyna się robić nużące i trochę zniechęcające. Pomyślmy jak łatwo jest pisać kod “rozgrzebany”, którego nie planujemy od razu kompilować i poprawiać tych wszystkich pomyłek, których kompilator nam zasygnalizuje. Porównajmy to z pisaniem kodu, który nie tylko jak najczęściej kompilujemy, ale i regularnie przepuszczamy przez własnoręcznie napisane testy! Toż to straszne, tak samemu kręcić na siebie bat :) Gdzie tu koderska wolność artystyczna? :D
Ale nie ma rady, czasami trzeba zakasać rękawy i testować…
-
Riddlemaster:
December 19th, 2008 o 16:09Unit-Testy są ok (co od dawna podkreślam w każdym możliwym miejscu) i potrzebne, ale żeby je stosować zawsze i wszędzie trzeba mieć faktycznie dużo samozaparcia. Trzeba też umieć je pisać (bo złe są jeszcze gorsze niż ich brak). Ostatnio rozbawił mnie kolega, gdyż mimo że podobno unit-testują, to przeszły błędy które nie miały prawa się pojawić. A to tylko dlatego, że nie wydzielili właściwych klas przypadków testowych :)
-
lmmilewski:
December 19th, 2008 o 18:06Bez testów jakoś tak głupio ;-) Tak jak iść spać bez backupu danych. Niby ok, ale cały czas się myśli co może się stać i co może źle zadziałać.
+ fakt, że testy są świetną dokumentacją. Zawsze wolę zajrzeć do testów niż czytać dokumentację.
@Riddlemaster: To niestety jest dość typowe dla ludzi, którzy zaczynają robić testy. Każdy chce pokazać jaki to jest “miszcz” z niego. Niby nie robi w ogóle błędów… Nikomu nie zależy na jakości kodu.
Ostatnio bardzo boleśnie odczuwam brak testów w kodzie, który “odziedziczyłem”. Nauczyłem się, że testy należy pisać od samego początku, bo potem może być trudno wprowadzić je do “gotowego” projektu.
-
Pi:
December 19th, 2008 o 22:12A myślałem, że ten brak notek spowodowany jest power levelingiem 70 – 80 ;p Cóż, taki powód też dobry ;)
-
moriturius:
December 23rd, 2008 o 11:29Nooo można też nie testować i mieć nadzieję, że działa :p
-
Xion:
December 23rd, 2008 o 21:44@Pi: Tę czynność wykonałem już kilkanaście dni wcześniej ;)
-
Pi:
December 26th, 2008 o 17:38Przywracasz wiarę w człowieka =D
Recent posts
