Download to read offline
Testing Django APIs
- 2. About me ● ProfessionalSoftware Engineer since June 2010 ● Django user since February 2018 ● Software Engineering Manager at ● SyDjango co-organiser since August 2019 @tyomo4ka
- 3.
- 4.
- 5. Dates ● Development startedin Feb 2018 ● Live since June 2019 Platform ● Python 3.6-3.7 ● Django 2.0–2.2 ● DRF 3.9-3.10 ● 49,520 LOC ● 826 tests run in ~52 sec on Bitbucket pipelines ● 86.9% code coverage XCore Facts
- 6.
- 7. Django ● Extends unittest ●Django helpers: client, settings, db fixtures, etc ● Extended and Django-specific assertions
- 8. Django ● django.test.SimpleTestCase –assertions, client, Django settings ● django.test.TransactionTestCase – reset db, fixtures, more assertions ● django.test.TestCase – wraps each test in atomic block ● django.test.LiveServerTestCase – starts a real server
- 9. Django Rest Framework(DRF) ● Replicates Django’s test cases ● Replaces default client with APIClient ● RequestsAPIClient testing against an external server
- 10. ● Unit testsare used to test the smallest bits of the application logic in isolation from the rest of the application ● Integration testing is used to test larger parts of the application which requires application communication with external services (db, files, queues, etc) Unit vs integration
- 11. Unit vs integration ●The same testing frameworks is usually used for both ● In most projects there is no way to run unit tests in separation from integration tests
- 12. Unit Integration API Cost Number of testson the project
- 13. Typical unit testscenario 1. Prepare SUT (System Under the Test) ○ could be skipped in many cases in others it’s as simple as manipulating with objects in memory ○ achieve test isolation using mocking framework ○ no real IO calls (DB, queues, HTTP) 2. Run SUT logic 3. Perform assertions ○ typically using data returned back to the test
- 14. Typical integration testscenario 1. Prepare SUT ○ Reset DB, queues ○ Load fixtures – DB, files, configs, etc ○ Best practice is to avoid calling external (from the app perspective) systems – use mock servers or mock Python IO calls 2. Run SUT logic 3. Perform assertions ○ typically checking the state of the system (DB, files, etc)
- 15. Unit vs integrationin Django ● Always base your TestCase class of SimpleTestCase when writing unit tests ● For integration and API tests use TestCase unless you really need to test transaction.on_commit logic in which case you need to use TransactionTestCase ● For UI tests use LiveServerTestCase
- 16. DB Fixtures (Django) ●Use dumpdata cli command to generate fixtures using data stored in the DB ● Import in TestCases fixtures class property
- 17. DB Fixtures (factory_boy) ●Simple inheritance (inc. traits) ● Generated values: sequences, lazy attributes, faker, fuzzy attributes ● Native integration with Django models ● Non-db objects (JSON structures, POPO objects, etc)
- 18. v2.0 pre-production and earlydays in production
- 19. pytest ● Run testsin parallel ● More flexibility around running tests ● Nicer output
- 20. pytest ● pytest --lfor pytest --ff ● pytest -k ● pytest --pdb ● markers, hooks, fixtures, etc ● plugins
- 21.
- 22. pytest-django ● --reuse-db ● setof useful django helpers
- 23. pytest-xdist ● run testsin parallel ● pytest -n auto or pytest -n ${NUM} ● pytest --looponfail (run tests on remote servers via ssh)
- 24. Tests run >50% faster with pytest-xdist
- 25.
- 26. pytest-sugar ● instafail ● niceprogressbar formatting
- 27.
- 28.
- 29.
- 30. HTTP requests mocking(responses)
- 31.
- 32.
- 33.
- 34.
- 35. Plans for thefuture ● Small cleanups: replace responses with vcr everywhere, small test refactoring ● Split test suite so we can run unit tests independently ● Smoke suite: migrate from Postman to pytest (or behave?) ● Add Hypothesis framework in some critical places ● Performance optimisation project: performance regression testing
- 36.
- 37. Quality is everyone’sresponsibility
- 38. Tests MUST runautomatically in CI pipeline
- 39. End-to-end tests areimportant
- 40. Writing tests beforecode sometimes is helpful
- 41. Testing is theway not a way
- 42. But sometimes skippingtesting is ok
- 43. What is notcovered in this talk? ● Postman tests (monitors, smoke suite) ● Performance tests with Locust ● XFT building another Django app for testing insurance price ● UI testing with Selenium ● Behavioral testing with behave
- 44. Thanks for listening! Feedbackis welcome Please reach me on Twitter @tyomo4ka