Testowanie aplikacji - TDD/BDD Rafał Łasocha @swistak35 http://swistak35.com 

TDD? BDD? ● TDD – Test-Driven Development ● BDD – Behaviour-Driven Development 

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 

Nie mam na to czasu. 

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 

Nie chce mi się tego uczyć. Nie mam na to nerwów. 

● 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. 

Ojtam, ojtam... 

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 

OK. Więc jak wygląda testowanie? 

RED 

GREEN 

REFACTOR 

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 

Back-end to jedno, a co z interfejsem? 

Jak najbardziej. ● Ruby: biblioteka Capybara – pozwala dogłębnie testować interfejs, opisuje zachowania (behaviour) użytkownika na stronie, np.: 

● 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.') 

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 

Czas na kilka linii kodu... 

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.