Miałem to wrzucić wcześniej, ale jakoś wypadło mi z głowy. Dziś trochę przegrzebałem forum i nie znalazłem tego wątku (jeśli gdzies mi umknął to sorry). W każdym razie - pewnie wielu z Was już się mniej lub więcej zagłębiło w temat, jednak chciałbym poznać Wasze opinie odnośnie wystąpienia DHH na tegorocznym RailsConf dot. (jak się okazało pomimo dość miłego początku ;)) w głównej mierze TDD.
Dla tych, którzy nie do końca wiedzą o co chodzi to:
a Wy co myślicie? DHH pozjadał wszystkie rozumy od siedzenia 10 lat przy Basecampie, czy może jednak ma trochę racji? a może ktoś z Was w tym roku w ogóle zrezygnował z testów?
Tak jak mówisz, DHH wywołał swoim wystąpieniem wiele reakcji i jedną z ciekawszych dyskusji na ten temat był kilkuczęściowy cykl rozmów Martina Fowlera, Kenta Becka i DHH:
Podczas tych dyskusji sam DHH trochę zszedł z tonu i trójka raczej zgodziła się co do kompromisowej opinii, że TDD to tylko narzędzie, które oczywiście niesie swoje koszty i korzyści. Nie należy dogmatycznie stosować, ale odrzucanie z definicji też nie jest do końca słuszne, bo jednak są miejsca w których TDD się sprawdza. Jednym z wniosków z tej dyskusji jest też to, że to także kwestia indywidualnych preferencji.
A, i nikt z tej trójki nie neguje konieczności samego pisania testów - kontrowersje budzi jedynie trzymanie się TDD.
@swistak84 - tak z ciekawości: pisałeś wcześniej zgodnie z TDD (a może trzymasz się dalej w niektórych wypadkach)? Co sprawiło, że uważasz tę praktykę za nie do końca dobrą? masz jakieś przykłady kiedy Cię zawiodła lub okazała się zbędna?
@sharnik - dzięki bardzo za uwagę, jest jak najbardziej na miejscu. Nawet pomimo tego, że wiem co to TDD
@pttr - dzięki za materiał, nie widziałem tego wcześniej i na pewno przeglądnę kolejne części Po pierwszej faktycznie widać, że podejście DHH do tego tematu jest dużo mniej emocjonalne niż na tegorocznym RailsConf. Ciekawe czy powtórzyłby swoje przemówienie raz jeszcze i w podobnym tonie po tych rozmowach z, nie da się ukryć, dość konkretnymi ludźmi
@ozim Moim zdaniem TDD prowadzi zwykle do wielokrotnego powtarzania czynności.
Założeniem TDD jest Test -> Code -> Refactor (repeat X times), problem jest to że jeżeli podchodzisz serio do refaktoringu to skończy się na tym że będziesz zmieniał kod na tyle mocno że testy przestaną mieć sens obecny, i w efekcie trzeba zrobić też refaktor testów.
Prowadzi to do tego że testy są zmieniane X razy równo z kodem. I w trakcie przebiegów refaktoringowych zwykle tak czy tak są mało uzyteczne bo refaktoring zmienia intrerfejs kodu.
Dodatkowo pisanie testów najpierw narzuca/sugeruje pewien schemat kodowania, który nie zawsze jest najodpowiedniejszy do danego zadania.
To dlaczego nie przepadam za TDD. Za testami jestem oczywiście jak najbardziej za, z tym że stosuję metodę (Code -> Refactor) x 2-3 -> Write test cases -> Refactor Code.
Często testy piszę po skończeniu całego modułu.
W ten sposób: Testujesz finalny interfejs, masz pewność że coś działała na przyszłość.
Minusem jest to że poszczególne metody modułu mogą zawierać błędy bo nie ma testów zanim cały moduł (albo większa jego część) nie zostanie napisana. Zaradzam temu zwykle starając się minimalizować rozmiar modułów.
Tak mówił John Hughes (współtwórca języka Haskell) na tegorocznym ClojureWest (będzie też na PolyConf w POZnaniu ;)). Szokujące było dla mnie, że metoda « testów generatywnych » jest starsza niż ja sam. Prelekcja w sposób fundamentalny zmieniła moja postrzegenie na testowanie. Można to obejrzeć tutaj.
Główny problem z test-first to sprzedawanie go jako metody zastępującej przemyślenie kodu przed napisaniem, bo przecież “wystarczy że napiszesz testy outcome’u i wtedy tworzysz minimalny kod który to spełnia”. No więc gówno prawda, nie wystarczy, a tak stworzony (z zastąpieniem myślenia przez napisanie “specyfikujących” testów) kod okazywał się wyjątkowo niezoptymalizowany i podatny na edge case’y.
dzięki Panowie za opinie - o takie właśnie konkrety mi chodziło. Sam też uważam, że TDD nie do końca się sprawdza, ale zawsze fajnie “posłuchać” co macie do powiedzenia.
taki off top trochę jeszcze, jeśli chodzi o edge case’y:
(scroll bar co prawda nie poszedł w świat, ale obstawiam, że ktoś mógł go tam przewijać w tle :D)
jesli piszesz test po, to testujesz, ale jedynie niektore sciezki. Pewnie najczesciej optymistyczna i najbardziej popularna w danym kontekscie “ficzera”
Po 2):
test first wymaga ogromu przemyslenia interfejsow API jakie udostepnisz za moment. O tym, ze robie to “bezmyslnie”, to pierwsze slysze
Ad 1) Moim zdaniem nic nie szkodzi aby przetestować wszystkie ścieżki po ich napisaniu.
Ad 2) Coś w tym jest, ale ja z kolei mam taki problem że rzadko piszę projekt od zera a nawet jakąś funkcję od zera. Zazwyczaj modyfikuję coś co już istnieje i nawet ma napisane testy. Teraz jak to widzę, to nawet jest to test first Bo testy już są i zaraz będą czerwone.
a może ktoś z Was w tym roku w ogóle zrezygnował z testów? 
Po pierwszej faktycznie widać, że podejście DHH do tego tematu jest dużo mniej emocjonalne niż na tegorocznym RailsConf. Ciekawe czy powtórzyłby swoje przemówienie raz jeszcze i w podobnym tonie po tych rozmowach z, nie da się ukryć, dość konkretnymi ludźmi 