Django/Python Test

unittest, py.test, django-nose, faker, Django, Python

Transcript

1. Python/Django Testing Pedram Dev
2. Why Test? v  Validate newly written code. v  Ensure application behavior has not changed due to refactoring or modifying of old code. v  Gives software credibility and makes it more ‘attractive’ within developer community. v  Prevents colleagues from inadvertently breaking code. Thus helps teams work together.
3. Testing Strategies v  Write testable code: v  Follow strict Object Oriented design paradigm. v  Don’t set global variables! Makes program state unpredictable. (we don’t do that, it naturally un- pythonic; FYI: if your coding in C variables outside a function have file-scope.) v  Test-Driven-Development: v  Write the test before writing the code. v  Person writing the code should write the test.
4. Test Pyramid •  As you climb the pyramid, test become significantly more time consuming and tedious. •  At the top you get high app coverage, but it’s hard to reproduce failures; need a debugger to figure out what went wrong. •  At the bottom it is easy to reproduce failures, no debugger needed. But you get the least app coverage; need a lot of unit-tests!
5. unittest concepts v  Test fixture: v  Any preparation needed to perform test. This includes but not limited to creating proxy databases, directories, or starting a server process. v  Test case: v  Smallest unit of testing. v  Test suite: v  A collection of test cases. Used to aggregate tests that should be together. v  Test runner: v  Orchestrates the execution of tests and produces outcome to tester.
6. great unittest v  Will fail when a bug has been introduced. v  Will Fail Fast, for instant feedback. v  Easy to understand what scenario is being tested and needs fixing.
7. Mock v  A python package that allows you to replace parts of your system under test with mock objects and make assertions about how they have been used. v  Designed for use with unittest. v  When we mock, we pre-program an object with expectations which form a specification of the calls they are expected to receive. (behavioral testing) v  Mocks vs Stubs = Behavioral testing vs State testing v  Stubs: provide canned answers to calls made during the test, usually not responding to anything outside what’s programmed in for the test.
8. Directory Layout •  Built-in test discovery will locate any file named “test*.py” under the current working directory. •  Can specify any filename pattern: •  $ ./manage.py test –pattern = ‘your_pattern.py’ •  For py.test, remove __init__.py module. (recommended)
9. v  Extends pythons unittest module. v  Provides function for writing timed tests, testing for exceptions, and short-hands for other functions in the unittest module. v  “if it looks like a test, it’s a test”; running tests is easier, and collecting test is automatic. v  Supports fixtures at the package, module, class, and test case level. v  Built-in plugins: output capture, error introspection, code coverage…
10. v  Integrates with other testing methods: nose, unittest. v  No boilerplate, speeds up development. v  Enhanced fixtures functionality: v  Scope for sharing fixtures (module and whole session) v  Yield fixtures v  Mocking/MonkeyPatch v  Data-base reuse: no need to re-create the test database for every test run.
11. v  py.test discovery mechanism (default can be changed): v  Test files: test_*.py v  Functions: test_* v  Classes: Test* v  Invocation: v  pytest.ini file: v  addopts (add options) v  Configure how py.test is executed
12. v  Marking(attrib—nose) with py.test: v  Create markers, and group tests together to potentially run together or exclusive of each other. v  Skipping or Failing: v  Can conditionally skip tests with markers. v  ‘xfail’(expected to fail); can temporary skip a certain test when you expect it to fail.
13. py.test fixtures v  Dependency injections: v  Fixture functions create and return fixture values v  Used to avoid mocking (implicit dependency) v  Important differences from unittest setup( ), is that fixtures in py.test are returned from a fixture function with appropriate naming; naming is used for injection in testing function.
14. v  fixtures can be cached on per scope basis: v  fixture functions can add finalizers(teardown): v  fixture functions can be parameterized: v  Modularity is possible: using fixtures from fixtures
15. v  A python package that generates fake data. v  Provides address, person, phone-numbers, country- code, language-code…
16. Best Practices v  If it can break it should be tested. Models, views, forms, template tags, validators, and so forth. v  Keep it simple and slim. v  Run tests whenever code is PULLed or PUSHed from the repo and in dev/qa environment before pushing to prod (write a hook that automatically does this). v  Common consensus in the community now is to avoid mocking/monkey-patching. Instead inject dependency and make it explicit.