Kilka lat temu przez internet przetoczyła się dyskusja na temat „Czy Test Driven Development (TDD) to martwa technika?”. Abstrahując od całej dyskusji, bo w zasadzie nie miała ona większego znaczenia. TDD to świetna technika, która w wielu przypadkach robi wielką różnicę, ale… I tutaj pojawia się to wielkie „ale”, o którym w dalszej części artykułu.
Co to jest TDD?
Jest to bardziej technika wytwarzania oprogramowania, niż technika pisania testów. Zbudowana jest ona na trzech fazach Red->Green->Refaktor. Najpierw piszemy test, który nie przechodzi (Red). Dopisujemy kod, który sprawia, że test przechodzi (Green). Ulepszamy kod testowanej metody i testu – jeżeli zachodzi taka potrzeba (Refactor). I w tym miejscu możemy wrócić do fazy Red, a wszystko do momentu, aż skończymy implementować dany kawałek kodu.
Czy da się szybko przejść na TDD?
W teorii wygląda to bardzo prosto. Wystarczy zacząć pisać najpierw test, a późnij kod. Wpasować się w schemat Red->Green->Refaktor i wszystko działa. Każdy przeciętny programista jest w stanie pojąć tą technikę w kilka minut 😉 A później zastosować na jakimś prostym przykładzie.
Ale prosty przykład tu nie wystarcza. A nawet, jak napiszesz wiele prostych przykładów, to też może nie pomóc. Na początku pisanie tą techniką może być bardzo powolne i będziesz potrzebował wiele wysiłku, żeby oswoić się z TDD. Potrzebna tu jest przede wszystkim zmiana mentalna.
„Przecież ja nie wiem jeszcze, co mam tutaj napisać”
Do TDD potrzeba więcej zaangażowania i zrozumienia „co ja tutaj tak właściwie robię?”. Większość programistów jednak wybiera drogę na skróty. „Coś tutaj napisze, a jak wyjdzie, to dopiszę testy”. Nie pamiętam ile razy już to słyszałem 😉
„Już skończyłem, tylko muszę jeszcze dopisać testy”
Dla większości programistów nie jest naturalne pisanie testu do kodu, który jeszcze nie istnieje. I zwolennicy TDD mogą się ze mną nie zgodzić, ale TDD daje nam obietnicę pisania lepszego kodu i ta obietnica w przypadku wielu programistów może się nie spełnić. Może dopiero po kilku latach pisania w TDD poczujesz się komfortowo z tą techniką. Co wcale nie znaczy, że nie warto próbować.
I to właśnie może sprawiać, że ta technika nie jest aż tak popularna. Chyba że się mylę i wszyscy piszą w TDD. Prawda? Daj znać w komentarzach.
Czy można komuś kazać pisać w TDD?
Wiele razy próbowałem przekonywać, kolegów do TDD i generalnie nie jest łatwo. To przekonywanie kogoś, żeby zmienił swoje myślenie, o tym jak pisze się kod. A każdy z nas kiedyś zaczął uczyć się pisania kodu od pisania kodu! W pewnym momencie dochodzą testy, a później ktoś mówi, że musisz pisać najpierw test a później kod.
Cóż, czasem niektórzy bulwersują się, że firmy w ogłoszeniach o pracę podają w wymaganiach testy jednostkowe. I oczywiście nie powinny tego podawać, to powinien być standard. Ale kwestia tego, czy zalecamy, czy wymagamy TDD jest już bardzo istotna.
Gdy dopiero raczkowałem z testami jednostkowymi i nie czułem się bardzo pewnie w tym temacie, to trudno mi było w ogóle stwierdzić, czy piszę testy w odpowiedni sposób. Gdyby ktoś wtedy wymusił na mnie TDD, to chyba byłoby jeszcze gorzej i z moją pewnością siebie i moimi testami. Więc może lepiej zachęcać i uczyć, zamiast narzucać.
Oczywiście nie mam na myśli przypadków gdzie firma jasno mówi, że u nas stosujemy TDD i jak nie ogarniasz to nie masz tu czego szukać…
Podsumowanie
Fajnie, że testy coraz częściej pojawiają się w projektach i coraz więcej developerów je stosuje. Praca nad projektami, w których nie ma testów jest generalnie koszmarem. A TDD może tutaj tylko pomóc, by testy były jeszcze lepsze.
Z drugiej jednak strony, codziennie startują nowe projekty i niestety w wielu z nich nie stosuje się testów w ogóle, co w dzisiejszych czasach może zastanawiać. Także nie ważne, jaką technika, ważne, że piszesz testy. A jeśli nie piszesz, to warto zacząć.
