Testy jUnitowe sa do dupy

Mowilem ci juz o tym czy nie, ze testy jUnitowe sa do dupy? Nie ? No to sluchaj... tzn czytaj...Co to wogle sa te testy jUnitowe? WTF? Gdzies po drodze wsrod ton klepanego kodu, gdzies gdzie jedni chcieli cos usprawnic, drudzy tylko odbebnic, gdzie cialge brakowalo czasu zetknely sie dwa pojecia: test jednostkowe i jUnit. W wyniku tego zetkniecia powstalo nowe super cool pojecie "testy jUnitowe". I teraz nie wiedomo czy chodzi o testy jednostkowe, integracyjne, alibi, czy jeszcze jakies inne.Co to wogle znaczy, ze ktos pisze, ze mam w projekcie testy jUnitowe poza tym, ze pewnie uzywa biblioteki jUnit? Czy tak trudno uzywac pojecia "test jednostkowy", "unit test"?. Wiec co jakis czas trzeba odkurzyc ten temat co udalo mi sie zrobic.
W projekcie, w ktorym pracuje poprowadzilem prezentacje o testach jednostkowych i bibliotece mockito. Korzystajac z tego, ze Staszek blisko jest i dosc czesto mozna pogadac o sprawach waznych z punktu widzenia software developera przeprowadzilismy kilka deskusji o mockowaniu, testowaniu jednostek kodu (publicznego api klasy, pojedynczej metody) i izolacji obiektow na potrzeby tesotwania jednostkowego. Zebrane przemyslenia zostaly dopieszczonem, ubrane w prezentacje i przedstawione ludziom z projektu.

Przebieglo to mniej wiecej tak, ze przygotowalem prosty model w domenie samochodowej, ktora to domene kazdy w projekcie rozumie. Bez zadnych problemow podefiniodaem zaleznosci i prosta logike. Samochod ma silnik, rame, nadwozie, elektornike.

Pewne odpowiedzialnosci zakapsulkowane sa w danych jego elementach. Elementy te zaleza od siebie i wspolpracuja ze soba. 

Przedstawilem jak odizolowac obiekt samochod, ktory byl testowany - mockujac wspolpracujace z nim obiekty. Pokazalem jak to zrobic w sposob bez mockow (test setup sie mocno wydluzyl) i jak to samo zrobic z uzyciem mockito.

Wszystko bylo banalnie proste, zamokowalem doslownie dwie metody w klasie silnik - wspolpracujacej z klasa samochod. Hmm tak sobie teraz mysle, ze dobrze by bylo podpiac to pod githuba zebys mogl zobaczyc o czm dokladnie pisze... (TODO: podlinkowac repo z githuba). Ludzie patrzeli na pisany kod i mogli sami stwierdzic co jest przyjemniejsze i co im bardziej lezy. Pierwsze spostrzezenia jakie im przyszly pokazaly jak przez pisanie testow zmuszamy sie do tworzenia lepszego designu. A to ze statyczne pola jakos zmienne globalne sa slabe, baaardzo slabe (cokolwiek to znaczy), a to ze inicjalizowanie w obiektow zaleznych przez operator new w konstruktorze obiektu glownego jest tez slabe :) A ja tylko kiwalem glowa i sie usmiechalem.

Podparlem sie prezentacja Staszka i praktycznym jego podejsciem i opowiadzialem jeszcze o przewadze

assertEquals(expected, actual)

nad assertTrue(warunek)

jesli chodzi o ilosc informacji zwracanych jest przez jUnita w razie niespelnienia asercji.

o szablonie given-when-then
 

po to aby latwo mozna sie bylo polapac, ktory fragment metody testowej co robi.

... i o pewnej ciekawej ksiazce:

Na koniec nasz projaktowy leader zachecil wszystkich do prezentowania tematow, ktore zycie w projekcie uczynic moga lzejszy. Ja mam juz kolejny temat jednak zanim go zapodam musze przygotowac grunt pod zmiany. O tym co to znacz bedzie w jednym z nastepnych postow.

Ty, drogi czytelniku tez pewnie masz cos do powiedzenia. Nie czekaj wciaz wciskajac sobie kit, ze jeszcze potrzebujesz tego i tamtego, ze sa lepsi co nic nie przedstawiaja i ze nie ma co wychodzic przed szerego bo jeszcze sie skompromitujesz. Daj spokuj, zmien nastawienie, zacznij sie dzielic tym co masz i nie obawiaj sie wzbudzac skrajnych emocji. Jedni beda cie kochac inni cie wysmieja, a ja chetnie sie dowiem co za temat zapodales i komu...