Test-Driven Development - principles of well crafted software
-
Upload
szymon-stepniak -
Category
Technology
-
view
88 -
download
1
description
Transcript of Test-Driven Development - principles of well crafted software
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