TDD (Test-Driven Development, programowanie sterowane testami) to metoda pracy, w której programista najpierw pisze test opisujący oczekiwane zachowanie, a dopiero potem kod, który ten test spełnia. Metodę spopularyzował Kent Beck.
Cykl red, green, refactor
- red: piszesz test, który na razie się nie powodzi,
- green: piszesz najprostszy kod, który sprawia, że test przechodzi,
- refactor: porządkujesz kod, pilnując, aby testy nadal były zielone.
Zalety i wady
TDD wymusza przemyślenie wymagań przed pisaniem kodu i daje zestaw testów chroniący przed regresją. Jest jednak mniej wygodne przy eksploracji, prototypach i interfejsach, których wygląd się zmienia. Wymaga też dyscypliny i doświadczenia.
Czy TDD jest potrzebne?
Nie zawsze. Najlepiej sprawdza się przy logice biznesowej, bibliotekach i naprawianiu błędów: najpierw test odtwarzający błąd, potem poprawka. W projektach wizualnych często wystarcza pisanie testów po wprowadzeniu zmian.
Przykład cyklu
Chcesz napisać funkcję liczącą rabat. Najpierw test: dla koszyka o wartości 200 zł rabat 10% ma dać 180 zł. Test się nie powodzi, więc piszesz najprostszy kod, który go spełnia. Potem dodajesz kolejny przypadek, np. brak rabatu dla małych kwoty, i znów kod. Na końcu upraszczasz implementację, a testy pilnują, aby nic się nie zepsuło.
Ma to bezpośredni związek z praktykami, na których opiera się pisanie czytelnego i zrozumiałego kodu.
Zobacz w praktyce
Clean Code - jak pisać czytelny i zrozumiały kod 
Jak automatycznie sprawdzić szybkość i jakość kodu przed wdrożeniem? 
Jak zmierzyć i spłacać dług technologiczny w projekcie Powiązane pojęcia
Wszystkie hasła z kategorii Programowanie i wzorce projektowe