TDD - Test Driven Development

W ciągu ostatniego tygodnia nie zrobiłem w projekcie niemal nic - główną przyczyną był, niestety, brak czasu i zmęczenie towarzyszące mi w nielicznych wolnych chwilach. Nie była to jednak jedyna przyczyna. Kilka razy udało mi się usiąść z zamiarem pisania kodu, ale wtedy uświadamiałem sobie że mimo ogólnej wizji tego, w którą stronę projekt ma zmierzać, nie bardzo wiem od czego zacząć i jak najszybciej osiągnąć kod, którego działanie będę mógł przetestować (a możliwość uruchomienia kodu i przetestowania jego działania jest ogromnym motywatorem). Postanowiłem spróbować przełamać niemoc twórczą dzięki TDD - Test Driven Development, czyli w wolnym tłumaczeniu "rozwój napędzany testami".

Idea TDD jest prosta: zaczynamy pisać kod od testów. Dodajemy test, który z początku nie będzie się nawet kompilował, bo kod, który ma testować, jeszcze nie istnieje, ale to nic. Kiedy mamy kod testu, piszemy fragment właściwego kodu - tyle, aby test zaczął przechodzić. Kiedy zobaczymy w wynikach zielony kolor, refaktorujemy kod (o ile zachodzi taka potrzeba) i piszemy następny test.

Takie podejście ma wiele zalet:

  • Osiągamy pełne lub niemal pełne pokrycie kodu testami, gdyż nie dodajemy kodu dopóki nie mamy nieprzechodzącego testu.
  • Łatwiej skupiamy się na definiowaniu wygodnego API - test jest zasadniczo kodem korzystającym z API udostępnianym przez testowany kod, więc już na etapie jego pisania będziemy widzieć, czy korzysta się z niego łatwo, czy nie, i będziemy mogli w razie czego wprowadzić zmiany.
  • Częścią powyższej korzyści jest to, że piszemy czystszy kod - żebyśmy mogli w ogóle napisać test, testowany kod musi mieć odpowiednią architekturę, która zwykle ułatwia późniejsze modyfikacje.
  • Na koniec, kwestia co do której mam nadzieję, że mi pomoże - od razu mamy wykonywalny kod, wykorzystujący funkcjonalność biblioteki (zakładając, że piszemy bibliotekę), więc na bieżąco możemy (a wręcz musimy) go uruchamiać i patrzeć, czy wszystko działa.

Są też, oczywiście, wady, z których główną dla mnie jest to, że dla niewprawionego programisty (czyli takiego jak ja :p) takie podejście jest niezbyt intuicyjne i trzeba się mocno pilnować, żeby nie wpaść w koleiny "najpierw funkcjonalny kod".

Dziś jest już późno, ale jutro powinienem w końcu mieć czas, aby wprowadzić ten pomysł w życie i zobaczyć, jak to się sprawdzi w praktyce. Wtedy też mam nadzieję mieć już materiał na kolejną notkę. Zatem - do jutra!