Upload
szymon-stepniak
View
88
Download
1
Tags:
Embed Size (px)
DESCRIPTION
Prezentacja na temat Test-Driven Development z dnia 29.01.2014, zaprezentowana w ramach Friday Java Labs
Citation preview
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