Kiedy (nie)korzystam z TDD

TDD (eng. Test-Driven Development) to technika tworzenia oprogramowania, która polega na pisaniu automatycznych testów jeszcze przed napisaniem docelowego kodu.

Podejście TDD spopularyzował Kent Beck na przełomie XX i XXI wieku, opisując je szczegółowo w swojej popularnej książce „TDD. Sztuka tworzenia dobrego kodu”.

Istotą TDD jest odwrócenie klasycznej kolejności działań. Zaczynamy od zdefiniowania wymagań w postaci testu. Gdy test zgłasza błąd, uzupełniamy aplikację o właściwy kod, tak aby test wykonał się poprawnie. Ostatnim, kluczowym krokiem jest refaktoryzacja, która dba o wysoką jakość i czytelność powstałego rozwiązania.

Moim zdaniem TDD to potężna metodologia, ale jej nadmierne stosowanie często okazuje się nieefektywne, ponieważ z każdą kolejną funkcjonalnością przygotowanie testu staje się coraz trudniejsze. Aby móc odtworzyć poszczególne przypadki, potrzebny jest coraz większy setup, czyli kod poprzedzający kod testów.

Z tego powodu staram się pisać testy na możliwie wysokiej warstwie np. w oparciu o Selenium, które weryfikuje funkcjonalność wystawioną dla końcowego użytkownika.

Ciężko jest pisać testy nie mając dostępu do działającej strony, a tym samym nie mając wiedzy o przejściach, lokatorach elementów oraz responsywności.

Z tego względu większość testów tworzę bez stosowania TDD. W moim przypadku wyjątkiem od tego podejścia są sytuacje, gdy:

• w kodzie pojawia się bug. W takim przypadku najpierw skupiam się na utworzeniu testu, który ten błąd wywołuje, a dopiero na kolejnym etapie dopisuję kod, który eliminuje napotkany problem.
• próbuję napisać złożony algorytm. Rozpoczęcie pracy od napisania testu pozwala mi na cykliczne ulepszanie rozwiązania, tak, aby w rezultacie końcowym właściwy kod przeszedł przez wszystkie przypadki testowe.