Thoughts on Tests

Extracted from a previous brainstorming session (edx-platform Code Structure: Hackathon XIV):

• • Unit tests 
    • Properties
      • Do not have dependencies on peer or higher layers.
      • May depend on low-level core libraries.
      • White-box tests of all edge conditions and paths.
    • Guidelines
      • Can use/test internal methods of the module.
      • Use override_settings instead of requiring settings in a central envs/tests.py.
  • Integration tests
    • Properties  (Note: this differs from testing.rst.)
      • End-to-end python integration tests that test dependencies between apps.
      • At least one inter-dependency is not mocked.
      • May test multiple paths, including non-happy paths if impacted by inter-dependencies.
    • Guidelines
      
      • Stored centrally
      • Only use exposed public interfaces
  • Acceptance tests
    • Properties
      
      • End-to-end UI-level black-box tests.
      • Mostly only happy paths are tested.  Regularly occurring exceptional paths that are integral to the user-facing feature may also be tested.
      • All scenarios described in user-documentation are typically covered.