Save 37% off PRO during our Black Friday Sale! »

[PL] Automatyzacja Testów

[PL] Automatyzacja Testów

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

E9713ac84ec5002229dc81eba8cd5c37?s=128

Łukasz Balcerzak

October 20, 2013
Tweet

Transcript

  1. Lukasz Balcerzak automatyzacja testów Sunday 20 October 13

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

    django, nose, tox, boom, vcs, hubot, django-compressor O mnie 2 Sunday 20 October 13
  3. ★ 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
  4. ★ Rodzaje testów ★ Proces testowania ★ narzędzia ★ Continous

    integration Plan Sunday 20 October 13
  5. ★ Testy jednostkowe ★ Testy integracyjne ★ testy regresyjne Rodzaje

    testów Sunday 20 October 13
  6. ★ Najprostsze tesy wejścia/wyjścia Testy jednostkowe 6 Sunday 20 October

    13
  7. ★ testują grupę elementów systemu testy integracyjne 7 Sunday 20

    October 13
  8. ★ 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
  9. ★ test-driven development ★ Documentation-Driven development ★ Behavior-driven development ★

    test coverage ★ code review proces testowania Sunday 20 October 13
  10. ★ Napisz testy ★ napisz kod test-driven development 10 Sunday

    20 October 13
  11. ★ napisz dokumentację ★ napisz testy ★ napisz kod documentation-driven

    development 11 Sunday 20 October 13
  12. ★ napisz oczekiwane zachowanie systemu względem użytkownika ★ napisz kod

    behavior-driven development 12 Sunday 20 October 13
  13. ★ http://pypi.python.org/pypi/coverage test coverage 13 Sunday 20 October 13

  14. ★ coś czego nie zautomatyzujemy ... ★ łatwo wyłapuje drobne

    błędy ★ oraz niejasności w kodzie code review 14 Sunday 20 October 13
  15. ★ podczas przeglądania kodu pamiętajmy, że jesteśmy delikatnymi duszami code

    review 15 Sunday 20 October 13
  16. ★ podczas przeglądania kodu pamiętajmy, że jesteśmy delikatnymi duszami code

    review 16 Sunday 20 October 13
  17. ★ 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
  18. jednostkowe czy integracyjne 18 Sunday 20 October 13

  19. jednostkowe czy integracyjne 18 Sunday 20 October 13

  20. ★ 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
  21. problem? 20 Sunday 20 October 13

  22. problem 21 Sunday 20 October 13

  23. poprawiony test 22 Sunday 20 October 13

  24. poprawiona metoda 23 Sunday 20 October 13

  25. ★ 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
  26. ★ 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
  27. ★ 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
  28. ★ 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
  29. ★ 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
  30. ★ jedna z najważniejszych cech dobrych testów szybkie testy -

    po co? 29 Sunday 20 October 13
  31. ★ 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
  32. perspektywa 31 Sunday 20 October 13

  33. perspektywa 32 Sunday 20 October 13

  34. perspektywa 33 Sunday 20 October 13

  35. ★ 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
  36. ★ 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
  37. ★ setup.py ★ przykładowa implementacja: https://github.com/ lukaszb/django-guardian/blob/master/extras.py jakość kodu 36

    Sunday 20 October 13
  38. ★ podstawowe ★ znane ★ mniej znane ★ specjalistyczne Narzędzia

    Sunday 20 October 13
  39. ★ shell ★ przeglądarka ★ psql ★ ipython ★ curl

    ★ ab/boom podstawowe 38 Sunday 20 October 13
  40. ★ unittest/doctest ★ nose ★ pytest ★ pyflakes/flake8 znane 39

    Sunday 20 October 13
  41. ★ 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
  42. ★ 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
  43. ★ sentry - wyjątki aplkikacji webowych ★ travis-ci - continous

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

    wielu wersji pythona/paczek problemy Sunday 20 October 13
  45. natychmiastowy feedback 44 Sunday 20 October 13

  46. ★ watchdog! natychmiastowy feedback ★ + notyfikacje 45 Sunday 20

    October 13
  47. natychmiastowy feedback 46 Sunday 20 October 13

  48. natychmiastowy feedback 47 Sunday 20 October 13

  49. natychmiastowy feedback 48 Sunday 20 October 13

  50. ★ ż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
  51. ★ py.test pozwala na “oznaczanie” testów natychmiastowy feedback 50 Sunday

    20 October 13
  52. natychmiastowy feedback 51 Sunday 20 October 13

  53. natychmiastowy feedback 52 Sunday 20 October 13

  54. ★ 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
  55. ★ instalacja tox 54 Sunday 20 October 13

  56. ★ plik tox.ini tox 55 Sunday 20 October 13

  57. ★ uruchamiamy dla wszystkich środowisk: ★ Albo tylko jednego: tox

    56 Sunday 20 October 13
  58. ★ testowanie różnych wersji pakietów tox 57 Sunday 20 October

    13
  59. ★ testowanie generowania dokumentacji tox 58 Sunday 20 October 13

  60. ★ “dziedziczenie” konfiguracji tox 59 Sunday 20 October 13

  61. ★ wymaga setup.py ★ generalnie niepotrzebny, jeśli nie planujemy zapewniać

    wsparcia wielu wersji python’a tox - wady 60 Sunday 20 October 13
  62. ★ jenkins ★ buildbot ★ travis-ci ★ zeus-ci continous integration

    Sunday 20 October 13
  63. ★ 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
  64. buildbot - platformy 63 Sunday 20 October 13

  65. buildbot - steps 64 Sunday 20 October 13

  66. ★ 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
  67. ★ wystarczy zalogować się na https://travis-ci.org ★ ... zarejestrować swój

    projekt ★ ... oraz dodać plik .travis.yml travis ci 66 Sunday 20 October 13
  68. travis ci - .travis.yml 67 Sunday 20 October 13

  69. ★ 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
  70. zeus-ci 69 Sunday 20 October 13

  71. ★ 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
  72. ★ 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
  73. ★ https://github.com/lukaszb/zeusci zeus ci 72 Sunday 20 October 13

  74. ★ https://github.com/lukaszb/zeusci ★ http://pypi.python.org/pypi/tox ★ http://pypi.python.org/pypi/pytest ★ http://pypi.python.org/pypi/nose ★ http://pypi.python.org/pypi/nose-alert

    ★ http://pypi.python.org/pypi/nose-watch Pytania? 73 Sunday 20 October 13