Guru Sorocaba - Testing in Django

Online Meetup organised by Guru Sorocaba, Brazil

Transcript

1. Testing in Django Kátia Nakamura May 3rd, 2017 @KatiaNakamura
2. Kátia Nakamura From Mogi das Cruzes, SP, Brazil Based in Czech Republic Master Degree in Computer Science (UNIFESP) Django Developer at Kiwi.com Traveling ✈ Photography Django Girls @KatiaNakamura
3. Tests @KatiaNakamura Based on my post
4. Tests: types • Unit Tests: ◦ Tests highly-specific parts of the code • Integration Tests: ◦ Tests small parts combined together @KatiaNakamura
5. "Why should I test?" @KatiaNakamura
6. "Why should I test?" @KatiaNakamura "Why shouldn't you?"
7. "Why should I test?" @KatiaNakamura Tests are important but… • "It takes time..." ⏳ • Low Priority: ⬇ ◦ there is always something more important to start/finish
8. "Why should I test?" @KatiaNakamura • Manually test for each change/scenario • Integration tests: ◦ Business logic is usually more complicated Soon enough: much more time finding and fixing those nasty bugs
9. "Why should I test?" @KatiaNakamura • Importance: ◦ guarantee that the last feature is working properly? ✅ ◦ start new task, stop after days/weeks and return to the previous one because of bugs you didn't catch?
10. "What should I test?" @KatiaNakamura
11. What you shouldn't test @KatiaNakamura • Built-in functions/libraries ◦ e.g.: datetime library in Python • Code built into the Framework ◦ e.g.: Model Fields in Django
12. @KatiaNakamura For everything else… "What should I test?"
13. @KatiaNakamura For everything else… … you should have tests. "What should I test?"
14. ◦ e.g.: custom methods for ▪ Models ▪ Views ▪ Forms ▪ Template tags ▪ Middleware ▪ etc. @KatiaNakamura "What should I test?"
15. @KatiaNakamura "When should I test?" • Test-After • Test-First (TDD - Test Driven Development) ◦ beginning: seems boring-repetitive-waste-of-time ◦ from the beginning, step-by-step with unit tests ◦ give a try
16. High-level Python Web Framework Free and Open Source @KatiaNakamura
17. @KatiaNakamura Testing in Django Back to 2006 Issue #2333
18. Back to 2006 "As an added incentive, this is a feature that is present in Rails." @KatiaNakamura Testing in Django Issue #2333
19. $ ./manage.py test @KatiaNakamura Testing in Django Testing in Django Highlight some points and few libraries mentioned in Ana's Talk
20. Factory Boy @KatiaNakamura Fixtures replacement tool • it allows the replacement of static and hard to maintain data for randomly generated inputs. Based on factory_girl
21. Factory Boy @KatiaNakamura
22. @KatiaNakamura Factory Boy
23. Generates fake data • better than generating random values is generating realist values Based on Ruby Faker - among others. @KatiaNakamura Faker
24. @KatiaNakamura Faker
25. @KatiaNakamura Factory Boy + Faker
26. @KatiaNakamura Factory Boy + Faker
27. @KatiaNakamura MutPy Mutation test tool • small alterations on the source code or bytecode • find possible weakness in the code
28. @KatiaNakamura MutPy Example by MutPy documentation
29. @KatiaNakamura MutPy $ # mut.py --target node --unit-test test_node $ mut.py --target calculator --unit-test test_calculator -m
30. @KatiaNakamura MutPy Example by MutPy documentation
31. @KatiaNakamura Model Mommy Smart way to create fixtures for testing in Django • simple and powerful API Inspired by great OSS like Ruby ObjectDaddy and FactoryGirl
32. @KatiaNakamura Model Mommy Example by model-mommy documentation
33. @KatiaNakamura Model Mommy Example by model-mommy documentation
34. @KatiaNakamura Model Mommy • skips fields with null=True or blank=True • use default values
35. High Coverage ≠ High Quality @KatiaNakamura Test Code Coverage
36. High Coverage ≠ High Quality Low Coverage: we don't have many tests written @KatiaNakamura Test Code Coverage
37. High Coverage ≠ High Quality Low Coverage: we don't have many tests written High Coverage: it doesn't mean anything... ...except that we reached a percentage of the lines of code at least once. @KatiaNakamura Test Code Coverage
38. "When testing, more is better." but also remember to: Refactor Remove unnecessary tests Remove those that are not being used anymore @KatiaNakamura Test Code Coverage
39. Refactor Remove unnecessary tests Remove those that are not being used anymore It's not only about writing more tests, but keeping the consistency of how everything should work. ✓ @KatiaNakamura Test Code Coverage
40. @KatiaNakamura Top 3 tips for speeding up your tests Be vigilant of what gets created in setUp() • Remove and/or reduce unnecessary code Don't save model objects if not necessary • in-memory model - Employee() instead of Employee.objects.create() Isolate unit tests • more simple unit test or pytest
41. @KatiaNakamura Example: Bakery • Product model • ProductQuestionnaire model • calculate the VAT (Value Added Tax) for products
42. @KatiaNakamura Example: Product
43. @KatiaNakamura Example: ProductQuestionnaire
44. @KatiaNakamura Try 1: Logic to views
45. @KatiaNakamura Try 1: Logic to views
46. @KatiaNakamura Try 2: Logic to forms
47. @KatiaNakamura Try 2: Logic to forms
48. @KatiaNakamura Try 3: separate class
49. @KatiaNakamura Try 3: separate class
50. @KatiaNakamura Functional tests are still really important to validate the contract between units
51. @KatiaNakamura • Recognise the value of having tests • Start from the beginning with simple unit tests • Testing will become part of your day
52. @KatiaNakamura Thanks! katiayn@gmail.com /katiaynakamura /katiayn