Test Driven DevelopmentTest Driven DevelopmentPrinciples of well crafted softwarePrinciples of well crafted software

Szymon Stępniak, 31.01.2014

„By 2022 it will be not possible to get a professional programming job if you do not practice TDD routinely.”

Allan Kellyhttp://allankelly.blogspot.com/2014/01/programmers-without-tdd-will-be.html

http://www.doolwind.com/images/blog/TestDrivenGameDevelopment.png

http://1minus1.com/userstorage/images/dev_graphs_testdrivendev.jpg

http://developpementagile.com/media/11006/chucknorristdd.png

3 prawa TDD Uncle Boba● Nie pisz linijki kodu produkcyjnego, dopóki nie napiszesz

testu kończącego się niepowodzeniem● Nie pisz więcej niż jednego testu kończącego się

niepowodzeniem● Nie pisz więcej kodu produkcyjnego niż jest to wymagane

przez nieprzechodzący test

1. Testy jednostkowe2. Testy integracyjne3. Testy end-to-end

Charakterystyka testów jednostkowych● Szybkość wykonywania● Izolacja● Ograniczenie do zakresu odpowiedzialności testowanej

jednostki (klasy, metody, funkcji, reguły biznesowej)

Po czym rozpoznać dobre testy jednostkowe?● Sprawdzają dokładnie to co zostało opisane w nazwie testu● Koncentrują się na interakcjach zachodzących w kodzie● Weryfikują reguły biznesowe za które odpowiedzialna jest

testowana jednostka, wraz z warunkami brzegowymi● Jeśli test nie przechodzi, powód jest jeden i jest on

jednoznacznie określony● Prezentują poziom co najmniej równy poziomowi kodu produkcyjnego!

„Złe” testy to takie, które:● Testują zbyt wiele● Nie pełnią roli dokumentacyjnej kodu produkcyjnego● Są podatne na mutacje● Przechodzą, nawet gdy testowana jednostka w kodzie

produkcyjnym nie działa zgodnie z kryteriami akceptacyjnymi● Nie wnoszą żadnej wartości!

Koncentracja na max. pokryciu kodu testami● Automatycznie testuję wszystkie settery i gettery● Stopień pokrycia kodu obiektów domenowych: 100%● Całkowity stopień pokrycia kodu: 96.4%

Jeśli moim celem jest posiadanie jak największej ilości testów oraz jak największego pokrycia, prawdopodobnie ukrywamy znacznie poważniejszy problem...

Koncentracja na max. pokryciu kodu testami● Żadna klasa nie jest testowana automatycznie● Stopień pokrycia kodu obiektów domenowych: 24%● Całkowity stopień pokrycia kodu: 63.2%

Czy teraz widzimy ukryty problem?

Wnioski płynące z drugiego przypadku● Kodzik nie był pisany za pomocą TDD (przypadki użycia i

testy były projektowane po napisaniu koda)● Co więcej, pisząc ten kodzik nie myśleliśmy o faktycznym

zapotrzebowaniu na dostarczane funkcjonalności● A zatem prawdopodobnie naszym celem nie było spełnienie

reguł biznesowych...● ... i stworzyliśmy 76% niepotrzebnego kodu w core domain.

Wysokie pokrycie kodu nie jest niczym złym...... o ile jest „efektem ubocznym” wielu dobrze przemyślanych przypadków testowych, a nie celem samym w sobie.

Testy należy traktować jako kryteria akceptacyjne

Definition of Done

Co daje nam stosowanie TDD?● Poczucie bezpieczeństwa● Zredukowaną ilość zbędnego kodu● Lepiej „skrojoną” architekturę● Brak obawy przed utratą pracy w roku 2022 :-)

Photo credits:Sunset as an exploding volcano http://www.sxc.hu/photo/116800Agenda 4 http://www.sxc.hu/photo/1328012