Django testing dos and don’ts

Note: Example code was dark background with gloomy fonts that no one could read.

mahalow 90401902

The presentation

  • Do: use AssertEquals/AssertNotEquals

    • Don’t: AssertTrue is not good
  • Do: Build TestCase Sub-classes

    • Don’t repeat yourself

      • Create users
      • Create objects
      • Log users in
      • Clear cache
    • Don’t make your reusable test methods not too complex

  • Do: Test all possible user cases

    • Analyze all possible exit points of a function
      • All returns
      • all expected exceptions
    • Shoot for 80% code coverage
  • Do: Test that data changes on success

    • Don’t just asset that the function ran successfully
    • If data has changed, assert that the DB holds updated data
    • If cache was manipulated, assert that it is correct
  • Do: Use controls for complex testing

    • Create a control record/object to make sure complex functions don’t touch unrelated elements.
    • Example: To check user deletion, create user_to_be_deleted and control_user
  • Do: Write very specific tests

    • in most cases, a given test function should be no more than 10-15 lines long (use your setUp function!)
  • Do: Test more than one type of use-case

    • Testing all error use-cases are as useful as testing for success
    • Success use-cases can still succeed, but for varying reasons over time.
  • Do: Keep your tests dirt simple. Don’t write tests that require tests of their own

    • Don’t: Write TestCase-specific Helper functions
  • Don’t: Test everything in one big TestCase

    • Use many test cases: test_managers, test_models, test_views
  • Don’t do these things

    • Write tests that go beyond your codebase
    • Use fixtures for everything
    • Write unnecessary code
    • Repeat yourself