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.
