[Polish] TDD i BDD

[Polish] TDD i BDD
Spotkanie Nazgula (http://nazgul.edu.pl/)
27.06.2012

Transcript

1. Testowanie aplikacji - TDD/BDD Rafał Łasocha @swistak35 http://swistak35.com
2. TDD? BDD? • TDD – Test-Driven Development • BDD – Behaviour-Driven Development
3. Na czym polega testowanie? • W skrócie: napiszmy kod, żeby przetestować swój kod. • Piszemy metody, które sprawdzają działanie naszych funkcji w aplikacji – czy zwracają odpowiedni wynik i czy zachowują się tak, jak tego chcieliśmy
4. Nie mam na to czasu.
5. TDD/BDD przyśpiesza programowanie, gdy... • Wydzielamy część metody do innej, aby spełniać zasadę DRY • Dopisujemy nową metodę, która korzysta z innej, i nieraz musimy tą starą odrobinę zmienić – sprawdzamy, czy reszta aplikacji przez to nie siądzie • Musimy przeprojektować część aplikacji • Zmieniamy przestrzeń nazw i chcemy sprawdzić czy wszystko działa poprawnie • Testy pisze się szybko (choć jest ich zazwyczaj sporo) • Dzięki testom wiemy dokładnie w którym miejscu jest błąd • Wiemy, że nie napisaliśmy niczego, co posypało projekt
6. Nie chce mi się tego uczyć. Nie mam na to nerwów.
7. • Zdecydowanie lepiej nauczyć się biblioteki do testowania, niż uruchamiać swoją aplikację 1000 razy dziennie w celu sprawdzenia, czy funkcja działa poprawnie. • Albo gdy musimy sprawdzić po raz n-ty, czy działa jakaś starsza, dawno zaimplementowana część projektu. • Testowanie samemu jest o wiele, wiele bardziej męczące, nużące, czasochłonne i zniechęca do programowania.
8. Ojtam, ojtam...
9. Coś jeszcze? • Bugi – gdy coś się pojawi, wiemy to na bieżąco, wiemy kiedy wystąpił problem. • Nie ma strachu, że wyślemy jako wersję 'produkcyjną' coś, co nie działa – testy kontrolują, czy aplikacja działa tak jak powinna • Testy działające jako specyfikacja projektu • Możemy przetestować metody, które w gruncie rzeczy, jeszcze nie działają, bo są zależne od innych (niezaimplementowanych) • Testy jako dokumentacja naszego kodu
10. OK. Więc jak wygląda testowanie?
11. RED
12. GREEN
13. REFACTOR
14. Etapy dodawania funkcjonalności w projekcie • RED – piszemy testy, które tą funkcjonalność sprawdzają. Oczywiście, wszystkie testy kończą się porażką, ponieważ nie mamy jeszcze napisanego kodu. • GREEN – piszemy kod, dążymy do tego, aby testy przechodziły pomyślnie – niekoniecznie piszemy optymalne rozwiązania • REFACTOR – optymalizujemy kod
15. Back-end to jedno, a co z interfejsem?
16. Jak najbardziej. • Ruby: biblioteka Capybara – pozwala dogłębnie testować interfejs, opisuje zachowania (behaviour) użytkownika na stronie, np.:
17. • visit registration_path • fill_in('First Name', :with => 'John') • fill_in('Password', :with => 'Smith') • check('A Checkbox') • click_link 'Sign up' • page.should have_content('You signed up, check your e-mail.')
18. Jak NIE testować? • Najpierw piszemy test, potem kod, nie odwrotnie. • Blogi i fora są skarbnicami wiedzy na temat przykładów różnych testów • Piszemy testy z GUI tylko tam, gdzie są takie potrzebne (zwykłe testy są szybsze) • Jest wiele skryptów/aplikacji, które wspomagają testowanie
19. Czas na kilka linii kodu...
20. Pytania? Rafał Łasocha @swistak35 http://swistak35.com Źródło: http://thesingularity.pl/blog/2012/jak-stracic-czas-na-tdd-i-nie-dostarczyc-na-czas/ (o tym jak nie powinno się testować aplikacji) Ponadto en.wiki, prezentacje i odrobina własnego doświadczenia.