Być może stali czytelnicy (mam takich?) pamiętają, że jakiś czas temu obkupiłem się w literaturę. Gdy ostatnio sprawdzałem został już tylko tysiąc stron, więc niedługo pewnie przyjdzie czas na nowe zakupy 🙂
Ostatnio spędziłem kilka dni na nadmorskiej plaży i z braku literatury fantastycznej postanowiłem wziąć na warsztat dzieło Kenta Becka – „TDD. Sztuka tworzenia dobrego kodu.” Pana Becka poznałem oczywiście dużo wcześniej. Jego nazwisko przewija się często przy tematach związanych z Agile czy Extreme Programming. Jego lista osiągnięć jest o wiele większa – spójrzcie choćby na Wikipedię – imponujące życie zawodowe. To, oraz fakt, że cały czas mam ogromną nadzieję, że wreszcie zrozumiem o co tyle szumu z tym całym TDD sprawiły, że bardzo cieszyłem się na myśl o tym że wreszcie ktoś kompetentny wyłoży mi wszystko jak kawę na ławę i w końcu mnie także olśni.
Bystry czytelnik po takim wstępie już wie, że niestety rozczarowałem się.
I nawet nie wiem od czego mam zacząć. Przede wszystkim może opowiem trochę o moim postrzeganiu TDD – otóż znam definicję, procedury z tym związane (red-green-refactor(blue wg Uncle Boba)), korzyści, jakie wszyscy wymieniają, ale nigdy jeszcze nie widziałem kogoś stosującego to podejście w rzeczywistym projekcie (nie amatorskim) oraz nigdy nie widziałem dużego zestawu testów, który nie powodowałby problemów przy dalszych pracach nad kodem. Mimo to wierzę, że w końcu ktoś mi to pokaże – pewnie dlatego właśnie kupuję książki jak ta dziś opisywana.
Jednak nawet Kent Beck ze swoim profesjonalizmem na jakichś 200 stronach nie potrafił przekonać mnie do TDD i powoli tracę nadzieję, że komukolwiek się to uda 🙁
Jakie mam zarzuty wobec tej pozycji?
Autor bierze jako przykład system w którym należy zaimplementować m.in. dodawanie do siebie różnych walut. Przez pierwszych 30 stron pisania testów dochodzi do stanu, który był oczywisty dla każdego kto nie ma pojęcia o TDD, a ma choćby nikłe o projektowaniu oprogramowania. To chyba mój główny zarzut wobec TDD – gdy zwolennicy tego podejścia opowiadają o nim, to chodzi tam zawsze o pisanie testu testującego minimalny wycinek wymagań przed napisaniem linijki kodu produkcyjnego, następnie dopisanie tegoż kodu, refaktoryzację i napisanie kolejnego testu. Przez takie podejście zawsze patrzymy tak jakbyśmy mieli klapki na oczach. Mimo oczywistych rzeczy otaczających nas, nie zważamy na nic i piszemy tę swoją minimalną funkcjonalność. Dzięki temu cały kod jest pokryty testami, ale za to może się okazać (i okazuje się często) słaby koncepcyjnie. To tak jakbyśmy w przestrzeni szukali maksimum metodą, która gwarantuje nam uzyskanie maksimum lokalnego. W automatyce są takie podejścia i wtedy mimo, że można uzyskać efekty dużo lepsze, zadowalamy się tym maksimum lokalnym. Tak samo postrzegam TDD – dostajemy maksimum lokalne, mamy kod pokryty testami, ale nic więcej. Gdybyśmy, być może, połączyli dwa podejścia – projektowanie przed przystąpieniem do kodowania, a następnie TDD, wyniki byłyby dużo lepsze a dojście do nich nie byłoby tak frustrujące – bo jak nazwać to, że przez kilka godzin piszemy kod, a następnie dochodzimy do tego, że tak naprawdę to nie o to nam chodziło? Gdybyśmy najpierw sprawę przemyśleli, obmyślili architekturę – choćby w podstawowym zarysie, to wtedy dużo efektywniej moglibyśmy pisać testy – tyle, że wtedy nie byłoby to już TDD. Nie programowanie sterowane testami. W ogóle jak to brzmi? Nawet gdy sam ten skrót przetłumaczymy na polski to już coś tu nie pasuje… Mam cały czas przeczucie, że programowanie nie powinno być właśnie sterowane testami, a po prostu testowane.
No, ale to co właśnie napisałem powyżej kłóci się z tym, co pisze sam Kent Beck. Daleki jestem od porównywania się z nim, ale ktoś w tym momencie się myli – z rachunku prawdopodobieństwa wychodzi, że ja, ale dlaczego dotąd nikt mnie z tego błędu nie umiał wyprowadzić? Nawet książką taką jak ta? Bo sprecyzujmy raz jeszcze – nie mam absolutnie nic przeciwko testowaniu, a wręcz przeciwnie, ale mam wrażenie że TDD to po prostu przereklamowane podejście, które nadaje się do małych kawałków kodu i niczego więcej, a ludzie którzy twierdzą inaczej po prostu dostają za to niezłe pieniądze. Patrząc na Uncle Boba i Becka to nawet by się zgadzało i mam wręcz wrażenie, że pisząc taką książkę Beck schodzi trochę z takiego piedestału, na którym stoi jako żywa legenda programistyczna, a zaczyna się trochę „sprzedawać” (modne słowo) biorąc pieniądze za wciskanie czegoś co nie do końca działa. Bo, spójrzmy prawdzie w oczy, nie istnieje „złoty młotek”. I im bardziej ktoś przekonuje mnie do tego, że sprzedaje panaceum i nie mówi kiedy to się będzie sprawdzało, a kiedy nie – tym bardziej staję się nieufny.
Tutaj przypomnę Macieja Aniserowicza, na którego prezentacjach zawsze słyszałem kiedy opisywana technika się sprawdzi, a kiedy tak nie robić. Podobnie Udi Dahan – mimo, że NServiceBus to jego dzieło, nie opisuje go jako sposób na każdy projekt.
Do tego w drugiej części książki naczytałem się o efemerycznych wzorcach, które wg mnie pełnoprawnymi wzorcami nie są (a przynajmniej nie wszystkie), lub są znane szerzej pod inną nazwą – to też, wg mnie – takie dodawanie treści na siłę, żeby dociągnąć do zakładanej objętości druku.
Schodząc już z autora, nie oszczędzę też tłumacza, który może i miał trudne zadanie – bo jak tłumaczyć terminy programistyczne na polski, ale nie wywiązał się z niego zbyt dobrze. Nie od razu dotarło do mnie znaczenie „obiekt wartości” czy też „logowanie łańcuchowe” czy jak mu tam.
Podsumowując – jeżeli ktoś uwielbia TDD i stosuje je wszędzie, proszę o kontakt. Komuś takiemu ta książka nie jest potrzebna, ale dałby on jej najwyższe noty. Dla sceptyków, biorąc pod uwagę powyższe, daję jej 4.5 w mojej skali ocen.
O jak miło być przytaczanym jako głos rozsądku! Dzięki ;).
A akurat konkretnie dzisiaj ukazał się podcast, w którym jako gość poopowiadałem o testach właśnie: http://foreverframe.pl/devreview-8-o-testach-z-maciejem-aniserowiczem/ .
Pozdro!
Dziękuję za uzupełnienie wpisu. Fajnie, że mam kolejne audycje do słuchania na rowerze 🙂 Pozdrawiam
Mnie to się wydaje że "mix" o którym wspomniałeś, jest nieunikniony. Mam podobne zdanie w tej kwestii (przynajmniej na razie). Może wynika to ze zbyt małego doświadczenia… może Pan Kent B. architekturę ma już dawno wygenerowaną w głowie… nie wiem… Na samym początku wspomina jednak (jeśli mnie pamięć nie myli) że TDD to nie remedium na wszystkie problemy, a przygotowywanie projektu tydzień przed kodowaniem nie skreśla go jako TDD. Co do książki, to aż tak zła nie jest, no przynajmniej w mojej opinii.
Może i nie – ciężko określić – na pewno przeczytać warto – choćby po to, by wyrobić własną opinię 🙂
[…] czas temu pisałem o moim stosunku do TDD. W skrócie – nie stosuję, ponieważ jak dotąd nie udało mi się znaleźć sensownego […]