W swojej pracy zawsze staram się stosować TDD i bardzo liczyłem, że zobaczę jak wygląda warsztat TDD profesjonalisty.
Dave Nicolette przygotował zestaw user-stories opisujące wymaganie funkcjonalne działania bankomatu. Cały developement odbywał się zgodnie z Pair programming.
Wszystko to wyglądało bardzo obiecująco, ale ze względu na brak ochotników do pierwszego user-story na scenę została wywołana jedyna dziewczyna z sali. Niestety nie miała pojęcia o TDD, nie znała JUNIT oraz Eclipse (miała zawodowo korzystać z NetBeans) a do tego stres oraz obsługa cudacznej klawiatury Mac, wszystko to spowodowało, że pierwsze user-story zostało zrobione po prawie 45 minutach!.
Dave Nicollette próbował pomagać "ochotniczce" i jednocześnie przekazać trochę informacji pozostałym uczestnikom, którzy albo się nudzili albo dawali nogi na inne trwające równolegle prezentacje.
Po tym falstarcie było już trochę lepiej...
W wielkim skrócie w TDD chodzi o to, aby tworzenie kodu było wymuszane pisanymi testami, a to, że jednocześnie walidujemy swój kod jest pewnym "pozytywnym skutkiem ubocznym".
TDD sprawdza się szczególnie dobrze jak nasze wymagania są opisane za pomocą use-case i user stories.
Oczywiście po stworzeniu kodu, nie usuwamy testów, które posłużą nam do testowania regresyjnego.
Jeśli pomimo tego na produkcji zostanie znaleziony błąd to są (powinny być) 2 możliwości:
- jeśli testy nie przechodzą, to taki kod nie powinien pojawic się na produkcji
- jeśli testy przechodzą, to oznacza, że nasze repozytorium nie zawiera testu testujący taki przypadek
Oprócz podstaw opisujących pojedynczą iteracje w TDD (napisz test, upewnij się, że test nie przechodzi, napisz minimalną ilość kodu aby test przeszedł, zrób refactor) przedstawiono dodatkowe wskazówki i wnioski:
- stosując TDD nie powinno się tworzyć, żadnego kodu jeśli test tego "nie wymusza"
- powinien zostac stworzony test dla każdej reprezentatywnej ścieżki
- powinno się testować zarówno HAPPY PATH jak i EXCEPTION PATH
- nie można wpadać w obsesje związana z miarą pokrycia kodu testami
- nie jest niczym niezwykłym jeśli rozmiar kodu testów jest 10 razy większy niz kodu aplikacji
- z technicznego punktu widzenia kody testów powinny być traktowane jak kod produkcyjny
W pewnym momencie sam miałem przyjemność "pokodować" na scenie, co było niezapomnianym przeżyciem.
Brak komentarzy:
Prześlij komentarz