Od ponad 3 lat używam TDD z lepszymi i gorszymi wynikami, zawsze koniec końców okazuje się, że kod napisany w TDD (nie TAD czyli nie dopisując testy post factum ale w prawdziwym TDD czyli pisząc testy NAJPIERW) sprawia najmniej problemów i jest najłatwiejszy do utrzymania i do modyfikacji. Czyli wydaje się, że TDD to świetne narzędzie, dlaczego zatem tak mało osób stosuję tą metodykę? Poniżej postaram się zebrać co popularniejsze wymówki. Jeśli macie swoje to proszę dopisywać.
1) Pisanie testów wydłuża programowanie/ trzeba napisać dwa razy tyle kodu
No cóż, to fakt, że trzeba napisać prawie 2x tyle kodu ale to nie jest jednoznaczne z tym, że programowanie trwa dwa razy dłużej. Proces programowania nie polega na klepaniu kodu jako takiego, klepanie kodu zajmuje najmniej czasu. Najwięcej czasu zajmuje obmyślenie tego co chcemy napisać. Cały ten proces odbywa się w głowie i przez TDD nie wydłuża się.
2) Pisanie testów podraża produkcję oprogramowania (bo przecież trzeba napisać 2x więcej)
Bzdura nad bzdurami. Koszt produkcji oprogramowania to nie tylko naklepaniu kodu, to wszystko co się dzieje od pomysłu do zakończenia wdrożenia u klienta. No i biorąc to pod uwagę, jeśli poświęcimy 2x albo nawet i 3x więcej czasu na pisanie w TDD (nie, żeby TDD wymagało 3x czasu – ale weźmy przypadek skrajny) ale dzięki temu otrzymamy kod, który ma 10x mniej błędów a poprawienie każdego z nich zajmuje ~15minut to okaże się, że pisanie bez testów – tak z buta tak naprawdę podraża koszt produkcji kilkukrotnie. Co z tego, że szybko napiszemy jeśli później, za tydzień lub dwa spędzimy cały dzień na poprawianiu błędów? Krótko terminowo TDD wymaga więcej energii i czasu (szczególnie zanim nauczymy się pisać dobre i wartościowe testy) jednak w dłuższej perspektywie taki kod generuje mniej bugów, mniej zgłoszeń i w efekcie czego kosztuje znacząco mniej pieniędzy.
3) Nie piszę testów bo to taki mały testowy projekcik – taki na szybko
Chyba jedna z większych pułapek. Po co myśleć nad architekturą i skupiać się na TDD jeśli ten prosty i banalny problem napiszę w kilka godzin, wszak jestem takim kozakiem, że przy tej pierdołce nie zrobię błędów. Nie jeden kozak rzucał mięsem nad takim projekcikiem bo częściej okazuje się, że trzeba dopisać jeszcze to i tamto i jeszcze coś i nagle projekt zaczyna być znaczący… tyle tylko, że wtedy zaczyna się zabawa z gów… eee… mamy bagno, a najgorsze w tym jest to, że często w takim projekcie już nie pojawiają się dobre wzorce – No bo to już tak ktoś napisał więc trudno…. Moim zdaniem, jeśli na 100% wiesz, że to będzie eksperyment to pisz bez testów, sprawdź co chciałeś a potem wywal całość. Jeśli musisz spędzić nad projektem kilka dni to lepiej zakasać rękawy i TDDzić od początku.
4) Mój klient/prezes/dyrektor/kierownik nie pozwala mi pisać testów
Serio? Nie uwierzę, że Twój klient może zabronić pisać testów, nie uwierzę, że prezes/dyrektor/kierownik przyjdzie i powie, nie pisz testów, pisz kiepski kod, który nie wiadomo co będzie robił. Jeżeli jakimś dziwnym trafem jednak znajdziesz się w takiej sytuacji, kiedy zabronią Ci pisać w TDD, jeśli zabronią Ci stosować dobre praktyki to jest to sygnał aby uciekać z firmy bo dzieje się źle. Jest jeszcze inny aspekt tej sprawy, aby pisać testy nie musisz mieć czyjejkolwiek zgody, możesz pisać je samemu we własnym zakresie, możesz je trzymać w osobnym projekcie i commitować do własnego repozytorium (np. gitowego) i tak wiem, że w niektórych korporacjach są bardzo restrykcyjne zasady, ale jeśli trafiłeś w takie miejsce to odpowiedz sobie na pytanie. Czy chcesz pracować niczym galernik na statku, nie mieć możliwości wyrażenia swojego zdania nawet w sytuacji, kiedy wiesz, że Twoja galera zbliża się do wodospadu?
5) Próbowałem pisać testy ale każda drobna zmiana powodowała, że setki testów przestawały działać
Jeśli drobna zmiana czy refaktoryzacja w kodzie spowodowała zaczerwienienie się setki testów to znaczy, że robiłeś to ŹLE. No cóż, nikt nie rodzi się z umiejętnością kodowania i nikt nie rodzi się z umiejętnością pisania dobrych i wartościowych testów jednostkowych. Trzeba czasu aby nauczyć się tego dobrze. Trzeba pisać testy aby nauczyć się pisać je w prawidłowy sposób. Nikt nie nauczy Cię tego za pomocą poradnika TDD dla opornych czy TDD w weekend. Niestety trzeba przysiąść i ćwiczyć.
6) Mockowanie jest trudne
Jest wręcz przeciwnie, mockowanie jest banalnie proste w swojej koncepcji. Jednak potrafi być ono trudne jeśli projekt systemu jest delikatnie mówiąc zepsuty. Pisząc bez TDD bardzo łatwo napisać kruchy monolit, którego testowanie jest prawie awykonalne. Nie znaczy to jednak, że mockowanie jest trudne – znaczy to tylko tyle, że trzeba podszkolić się z budowania elastycznego i otwartego na zmiany kodu.
7) Nie mamy czasu na pisanie testów
Chyba najczęstsza wymówka z jaką się spotkałem. Co ciekawe najczęściej brak czasu spowodowany jest tym, że pół dnia poprawia się błędy, które przecież nie pojawiły się w kodzie same. Czyli pół dnia poprawiamy błędy zamiast pisać nowy kod, fascynujące a jakie motywujące przy okazji. Wyobrażasz sobie sytuację, że np. cały etat jednego człowieka w zespole poświęca się na to aby poprawiał błędy? Motywacja do pracy musi sięgać zenitu. Zamiast zainwestować w metodykę pracy, która daje lepsze rezultaty zmarnujmy energię na znalezienie wymówki aby tego nie robić a potem wróćmy do swojego kieratu pod tytułem szybko napisać kod byle jak byle by był bo przecież trzeba trzeba poprawiać błędy. Logika wprost powalająca na kolana nieprawdaż?
8) Później dopiszę testy
Taa.. jasne. Pomijając drobny szczegół czyli jaki wpływ na kod ma samo TDD, to najczęściej nie będzie się nikomu chciało dopisywać testów do czegoś co przecież już działa. Inna sprawa, że jeśli jednak dopisze się testy, to mają one skłonność do testowania implementacji a nie zachowania to po pierwsze a po drugie, jeśli kod zawiera jakieś błędy, to takie testy post factum często (chociaż nie zawsze) po prostu cementują błąd na zawsze.
Uncle Bob mówi, że pisanie testów dla programistów jest jak mycie rąk przez lekarzy przed operacją. Jest to kwestia profesjonalizmu i bez względu co powie pacjent i pod jaką presją działa lekarz to zawsze jakoś ma czas na umycie rąk przed zabiegiem. Tak samo powinni postępować programiści. Na to stwierdzenie usłyszałem kiedyś, że to jest przesada bo to co innego, bo inna branża…… itd. Życie podało mi piękny kontrargument. Firma tworząca oprogramowanie dla branży security, “… wiesz, jak sygnał z np. napadówki nie dotrze do centrali to może być zagrożone ludzkie życie”. Nie piszesz tego typu systemów? Piszesz przysłowiowe systemiki do fakturek? Skąd wiesz, jak zareaguje księgowa albo prezes firmy, który używa twojego oprogramowania, gdy z powodu drobnego błądziku w kodzie przyjdzie skarbówka przetrzepać wszystkie papiery w tej firmie?
A z jakimi wymówkami Wy się spotkaliście lub jakie macie aby nie pisać w TDD?
