Jeszcze jeden powód, dla którego testy działają mi na nerwy.
Zdaję sobie sprawę, że ten fakt niekoniecznie dobrze o mnie świadczy, jako o koderze… Ale gdy coś piszę, to zauważyłem, że dość często wprowadzam dość drastyczne zmiany w tym, co napisałem wcześniej.
Jeśli miałbym pisać testy na bieżąco, to każda taka zmiana automatycznie niesie za sobą konieczność wprowadzenia analogicznej zmiany w testach. To jest podwójnie upierdliwe i co gorsza, odciąga moją uwagę od tego, jak powinienem to wszystko ułożyć, żeby ze sobą współdziałało.
Te częste drastyczne zmiany to właśnie czas, w którym kod zostaje nadziany największą ilością bugów. A te to dopiero są upierdliwe. Zwłaszcza, że najlepsze nie spieszą się z wyjściem na jaw i dadzą o sobie znać, gdy już nie będzie oczywiste, w którym momencie się wylęgły
Nie jestem pewien, jak TDD mógłby tu coś pomóc.
Czas między powstaniem a identyfikacją buga jest skrócony do praktycznego minimum.
Teoretycznie TDD ma m.in. zapewnić, że ja sam rozumiem specyfikację funkcji, którą właśnie piszę. Ale jeśli za pół godziny zorientuję się, że ta właśnie specyfikacja wymaga zmian?
To oczywiście możliwe. TDD daje to, że design musisz sobie w miarę skonkretyzować przed implementacją. Napisanie niedziałających jeszcze testów jest akurat bardzo szybkie, a przy odrobinie szczęścia już wtedy jesteś w stanie wyłapać już pewne błędy projektowe (jak po prostu to, że klasy się dobrze ze sobą nie spasują).
Programując tradycyjnie, czyli sobie improwizując, ten końcowy design i tak przecież musisz mieć, tylko trzymasz go podświadomie w głowie, a wtedy trudniej zauważyć, że coś jest z nim nie tak - tak samo jak w szachy trudniej gra się na ślepo
Oczywiście i tak możliwe jest, że co pół godziny trzeba będzie zmienić implementację - ale jest to przecież postęp w stosunku do konieczności zmieniania jej np. co 10 minut ; )
(Teoretycznie pewnie powieniem najpierw rozrysować sobie cały projekt na kartce
Całego projektu, to przecież niemożliwe. Jakichś jego wycinków. I właśnie taką formą rozrysowania jest napisanie testów, z tym, że ta "kartka" nie zostaje zmarnowana, bo masz już kod testowy, do którego trzeba już tylko dociągnąć implementację.
Uczciwie mówiąc ja nie jestem jakimś adwokatem TDD i nie uprawiam go w ścisłej formie. Co nie zmienia faktu, że staram się, żeby pisanie testów przeplatało się przynajmniej z implementacją, nawet jeśli implementacja idzie przodem. Nie najlepszą, choć często spotykaną praktyką jest wykończyć jakąś funkcjonalnosć i dopiero po wszystkim, "na deser", dorabiać do niej testy.