Upgrade to Pro — share decks privately, control downloads, hide ads and more …

[PL] Automatyzacja Testów

[PL] Automatyzacja Testów

Talk I gave at PyCon PL 2013 about test automation (in polish).

Avatar for Łukasz Balcerzak

Łukasz Balcerzak

October 20, 2013
Tweet

More Decks by Łukasz Balcerzak

Other Decks in Programming

Transcript

  1. ★ Łukasz Balcerzak ★ autor django-guardian ★ commity m.in. w:

    django, nose, tox, boom, vcs, hubot, django-compressor O mnie 2 Sunday 20 October 13
  2. ★ mam szczerą nadzieję, że przynajmniej część z was zobaczy

    na tej prezentacji coś nowego po co kolejny talk o testowaniu? 3 Sunday 20 October 13
  3. ★ zabezpieczenie przed zmianami w przyszłości ★ ... lub po

    wykryciu błędu ★ Po zgłoszeniu błędu najpierw zastanówmy się jak go zreprodukować i proces ten zapisujemy jako test testy regresyjne 8 Sunday 20 October 13
  4. ★ test-driven development ★ Documentation-Driven development ★ Behavior-driven development ★

    test coverage ★ code review proces testowania Sunday 20 October 13
  5. ★ napisz oczekiwane zachowanie systemu względem użytkownika ★ napisz kod

    behavior-driven development 12 Sunday 20 October 13
  6. ★ coś czego nie zautomatyzujemy ... ★ łatwo wyłapuje drobne

    błędy ★ oraz niejasności w kodzie code review 14 Sunday 20 October 13
  7. ★ dużo testów jednostkowych i mało integracyjnych ★ bez paranoi:

    TDD ma nam pomagać a nie zabierać czas ★ dbać o to by, testowanie było łatwe ★ ... i szybkie no dobra, to jak testować? 17 Sunday 20 October 13
  8. ★ najpierw opiszmy oczekiwane zachowanie systemu ★ Powinniśmy testować wszystkie

    kombinacje parametrów wejściowych ... ★ a także różne kombinacje w różnych kontekstach, ale ... jednostkowe czy integracyjne 19 Sunday 20 October 13
  9. ★ nie dajmy się zwariować ★ nie chodzi TYLKO o

    kwestie biznesowe - chodzi o nasz zespół, który bardziej czeka na poprawkę lub funkcjonalność niż test ★ ... ale użytkownik też doceni, jeżeli np. jego poczta znowu zacznie działać i nie będzie musiał czekać, aż programista będzie łaskaw napisać test regresyjny bez paranoi 24 Sunday 20 October 13
  10. ★ staszek jest świetnym programistą ★ ma 10+ lat doświadczenia,

    uprawia tdd, pomaga współpracownikom, chłonie wiedzę i dzieli się nią ★ ale staszek raz na jakiś czas spędza 2 dni na napisanie testu ★ do jednej funkcji/poprawki, którą napisał w 15 minut paranoja 25 Sunday 20 October 13
  11. ★ staszek pracuje nad nowym projektem, w którym zdecydowano użyć

    nieznanych mu narzędzi i bibliotek ★ narzędzia mają świetną dokumentację jak poprawnie pisać kod i testy (hint: angularjs) ★ ale staszek nie zna jeszcze tych wspaniałości i nie ufa im zbytnio - więc i tak ręcznie testuje swoją aplikację ★ EPIC FAIL paranoja 26 Sunday 20 October 13
  12. ★ gdy nie jesteśmy pewni jak testować - nie próbujmy

    się oszukiwać, że mamy testy automatyczne ★ gdy napisanie testu zajmuje nam zbyt długo - dajmy spokój. Test napiszemy, jak wpadniemy jak to zrobić. ★ gdy widzimy, że ktoś wpada w paranoję: obrońmy go przed samym sobą! paranoja 27 Sunday 20 October 13
  13. ★ tzn. uruchamianie testów dla danego projektu powinno sprowadzać się

    do uruchomienia jednej komendy ★ ... co często wymusza łatwy “bootstrap” projektu ★ dla paczek: python setup.py test (dba o zależności) łatwe testowanie? 28 Sunday 20 October 13
  14. ★ jak często otrzymujemy informację o popsutych testach na serwerze

    CI? ★ ile maksymalnie mogą trwać testy żebyśmy je uruchamiali po każdej zmianie? 1h? 30m? 10m? 5m? 5s? 2s? ★ feedback, malarz, perspektywa szybkie testy - po co? 30 Sunday 20 October 13
  15. ★ mało testów integracyjnych ★ dużo mockowania ★ obserwacja najwolniejszych

    testów ★ sprawdźmy dokumentację (django auth, simpletestcase) ★ setUp vs setUpClass ★ czy naprawdę potrzebujemy tych wszystkich danych dla każdego testu? szybkie testy - jak? 34 Sunday 20 October 13
  16. ★ jakość kodu (pyflakes/flake8) ★ przykłady w docstringach (doctesty) ★

    generowanie dokumentacji ★ command line tools (np. scriptest) co testować poza kodem? 35 Sunday 20 October 13
  17. ★ shell ★ przeglądarka ★ psql ★ ipython ★ curl

    ★ ab/boom podstawowe 38 Sunday 20 October 13
  18. ★ lettuce (bdd) ★ freshen (bdd, łatwiejsze regexy) ★ splinter

    (~selenium, ale ma wspólne api dla różnych sterowników) ★ zc.buildout (automatyzuje ustawianie środowiska) mniej znane 40 Sunday 20 October 13
  19. ★ funkload - testy wydajnościowe pisane jak unit testy ★

    porunga - testowanie algorytmów ★ sqlmap - testy aplikacji w poszukiwaniu podatności sql injection ★ tox - testowanie dla różnych wersji Python’a i/lub zależności specjalistyczne 41 Sunday 20 October 13
  20. ★ sentry - wyjątki aplkikacji webowych ★ travis-ci - continous

    integration ★ coveralls - pokrycie kodu testami usługi 42 Sunday 20 October 13
  21. ★ natychmiastowy feedback ★ uruchamianie części testów ★ lokalne testowanie

    wielu wersji pythona/paczek problemy Sunday 20 October 13
  22. ★ żeby pozwolić sobie na uruchamianie testów po każdej zmianie

    pliku nasze testy muszą być bardzo szybkie ★ możemy też po prostu uruchamiać tylko te testy, które dotyczą zmienianej przez nas funkcjonalności natychmiastowy feedback 49 Sunday 20 October 13
  23. ★ pozwala na łatwe definiowanie środowisk testowych ★ korzysta z

    virtualenv i distribute ★ możemy uruchomić testy dla różnych wersji python’a ★ umożliwia uruchamianie dowolnej komendy, więc możemy na przykład sprawdzać generowanie dokumentacji tox 53 Sunday 20 October 13
  24. ★ wymaga setup.py ★ generalnie niepotrzebny, jeśli nie planujemy zapewniać

    wsparcia wielu wersji python’a tox - wady 60 Sunday 20 October 13
  25. ★ ponad 10 lat rozwoju ★ architektura master/slave ★ działa

    na wszystkich popularnych platformach ★ łatwo przechowuje się konfigurację w repozytorium ★ python! buildbot 62 Sunday 20 October 13
  26. ★ tak naprawdę jest to framework, nie gotowy produkt ★

    czasami gubi logi ★ czasami slave’y tracą połączenie z master’em ★ siermiężny interfejs buildbot - wady 65 Sunday 20 October 13
  27. ★ wystarczy zalogować się na https://travis-ci.org ★ ... zarejestrować swój

    projekt ★ ... oraz dodać plik .travis.yml travis ci 66 Sunday 20 October 13
  28. ★ niby open source, ale ... - zależy od zewnętrznych

    usług (np. websocket’y) - separacja codebase’u (backend/frontend) utrudnia deployment ★ limit czasowy (50min lub 10min jeśli nie ma logów) travis ci - problem? 68 Sunday 20 October 13
  29. ★ User experience ★ różne platformy ★ produkt i framework

    ★ build matrix ★ skalowanie slave’ów ★ łatwość wdrożenia ★ api ★ rozszerzalność ★ github PR support ★ rozpoznaje tox’a zeus ci - cele 70 Sunday 20 October 13
  30. ★ python 2.6/2.7/3.3+ (choć celujemy w 3.3+) ★ django ★

    django-rest-framework ★ celery ★ angular.js zeus ci - technologie 71 Sunday 20 October 13