[PL] Automatyzacja Testów

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

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