Dlaczego powstało Test-Driven Development?

Jak większość obecnych metodyk, tak i Test-Driven Development powstało jako dopełnienie wcześniejszych, w tym wypadku Test-First Programing istniejącego już od początku 1999 roku. Podobnie jak wszystkie przed nią musiała się zmierzyć z wyzwaniami i oczekiwaniami stawianymi przez przyszłych projektantów i programistów.

Skoro metodyki skupiające się na testach systemów istniały już wcześniej,
to rodzi się pytanie: „Dlaczego tyle systemów było tak słabo przetestowanych?”. Na tak postawione pytanie nie ma jednoznacznej odpowiedzi. Istnieje kilka.

Po pierwsze należy zauważyć, że nawet używanie najlepszych dostępnych narzędzi nie gwarantuje sukcesu. W tym przypadku było podobnie. Niewyczerpujące, źle napisane testy lub w ogóle ich brak, powodował, że kod obfitował w różnego rodzaju pułapki, które powodowały konieczność wprowadzania kosztownych poprawek, bądź wycofanie z użycia.

Kolejnym błędem było pisanie testów po zakończeniu prac na częścią implementacyjną lub w momencie, gdy osoba za nie odpowiedzialna zajmowała się już czymś innym. W takich sytuacjach jest już za późno na napisanie testów, a te które powstaną nie obejmują całej dziedziny problemowej i są kompletnie nieprzydatne. Dlatego TDD wymusza na deweloperach pisanie testów przed stworzeniem jakiejkolwiek implementacji. Gwarantuje to, że twórca w pełni rozumie zagadnienie nad którym pracuje.

Metodyka wymaga, by testy jednostkowe pisane były przez osobę, która będzie odpowiadać za implementację. Związane jest to z faktem, że pisanie testówpozwala odkrywać istotne aspekty domeny.

Kolejnym możliwym źródłem problemów, może być sposób, w jaki wykonywane są testy. Jeśli nie są zautomatyzowane, to są nikłe szanse, aby były wykonywane regularnie i zawsze w identyczny sposób. Nie wykonają zadania do którego zostały stworzone.

Ostatnia ważna rzecza jest tworzenie testów w taki sposób, żeby chroniły system przed wprowadzaniem błędów regresyjnych. Przy tym trzeba pamiętać, że wraz ze zmianami implementacji powinny zmieniać się testy. Architektura testów jest tak samo ważna jak architektura implementacji.

Przy użyciu zaleceń i procedur postępowania dostarczonych przez metodykę Test-Driven Development można uniknąć wszystkich powyższych problemów^.