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

Ł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