Kiedy zaczynam rozmawiać o TDD (Test Driven Development), przeważnie spotykam się z dwoma reakcjami. Albo ktoś jest bardzo podekscytowany, albo reaguje agresywnie. To jest chyba jeden z tych tematów, które dzielą branżę na pół. Chociaż nigdy nie przekonuję nikogo, że to jest lek na całe zło. Nic nawet nie obiecuję, ale czasem czuję się jak sprzedawca odkurzaczy.

 Dla jednych TDD są ciekawą zabawą, czymś podobnym do sudoku, albo krzyżówek. Dla innych to proces, z którego korzystają w codziennej pracy. Są też tacy, którzy próbowali, ale coś poszło nie tak i teraz ewangelizują nieświadomych zwolenników. Większość z nas jest gdzieś pomiędzy. TDD uczy nas i bawi, ale mamy niejedną wywrotkę na swoim koncie.

Co nam daje ćwiczenie Test Driven Development?

Moim zdaniem ćwiczenie TDD dużo zmienia w głowie. Nie tylko pozwala na pisania testów, co już samo w sobie jest wartościowe. Zmusza nas też do pisania testów pod wymagania biznesowe, a nie naszą implementację. To nie to samo 😉 Programiści często piszą testy, które mają potwierdzić, że ich kod działa, a nie sprawdzić czy działa. W TDD na etapie pisania testu nie ma jeszcze implementacji. Jedynym kompasem jest więc opis problemu.

Jeśli pracujesz z wymogami biznesowymi, lepiej projektujesz swój kod. Widzisz wzorce szybciej, bo nie skupiasz się na detalach. Uczysz się zwinności. Nie planujesz wszystkiego, tylko idziesz do celu małymi krokami. Dopasowujesz się w trakcie. To trochę tak jak górska wędrówka. Masz zaplanowaną podróż jednym szlakiem, ale może zmienią się warunki i pójdziesz innym. To uczy pokory, nie zawsze masz rację. Czasem wycofasz się ze swoich pomysłów, bo założenia były błędne. Dla mnie TDD jest jak dobra planszówka, planujesz, działasz, sprawdzasz, reagujesz.

Czy TDD poprawi jakość Twojego projektu?

Nie wiadomo, czy pisząc testy przed implementacją poprawisz jakość kodu w całym projekcie. Nie ma badań, które jednoznacznie to potwierdzą. Badanie jakości to w ogóle ciężki temat. Jednak poproszono programistów używających na codzień TDD o wyrażenie subiektywnej opinii. Zdaniem większości jakość kodu się poprawiła. Głównie ze względu na jego czytelność i testy.

Bez względu na to, czy piszesz testy przed implementacją, czy po, warto ćwiczyć TDD. Nie tylko zdobywasz nowe umiejętności, ale przede wszystkim rozwijasz swoją kreatywność. Wybierasz niecodzienne problemy, z którymi rzadko masz do czynienia w pracy. Dodatkowo budujesz portfolio na GitHubie. Jeśli robisz to regularnie, widać wyraźnie Twoje postępy.

Dlatego właśnie wybrałam TDD jako temat na moje 16 linijek w wyzwaniu #code16challenge. Żeby pokazać jak łatwo można zacząć. Jeśli Ty już wiesz, że chcesz się nauczyć tego procesu, to sprawdź program warsztatów TDD.