Test Driven Development

Technika ta wymaga od developera ogromnej dyscypliny i cierpliwosci. Jednakże lista korzyści wynikająca z takiego podejścia jest bardzo długa:

• kryteria akceptacji - przed rozpoczęciem pisania kodu aplikacji zaczynamy pisać testy jednostkowe jako znacznik implementacji konkretnych wymagań. Bez tej listy nie jesteśmy w stanie rozpocząć zadania
• koncentracja - ponieważ w jednym momencie pracujemy nad jednym testem nasza cała uwaga skupia się wyłącznie na ułamku funkcjonalności
• publiczne API - pisanie testu jednostkowego przed pojawieniem się kodu testowanego wymusza na nas precyzyjne i lepsze określenie interfejsów publicznych naszej funkcjonalności
• czystszy kod - ponieważ w TDD pracujemy jedynie na publicznych interfejsach komponentów mamy większą świadomość tego co należy a czego nie należy w nich publikować (aby m.in. uniknąć konieczności wspierania publicznej funkcjonalności w przyszłości)
• zależności - pisząc testy jednostkowe przed pisaniem kodu wymusza na nas dokładną analizę (i mockowanie) zależności naszego komponentu co sprawia, że na wskutek analizy możemy ograniczyć ich ilość
• bezpieczniejszy refaktoring - posiadając bazę testów zabezpieczających wymagania naszego produktu jesteśmy w stanie przeprowadzić liczne sesje refaktoringu upewniając się, że na ich końcu funkcjonalność systemu nie została utracona/zepsuta
• mniejsza liczba błedów - lepsze pokrycie testami oraz dokładniej przemyślany system już na poziomie komponentów powoduje generowanie mniejszej ilości błędów przez developera
• dokumentacja - testy tworzone w ramach TDD są odzwierciedleniem wymagań stawianych przed produktem, a więc są żyjącą jego dokumentacją