[Polish] TDD i BDD

[Polish] TDD i BDD

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

0c9087813222ecf3d5ff0014488d50e1?s=128

Rafał Łasocha

June 27, 2012
Tweet

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.