DjangoCon Testing Tutorial

DjangoCon 2011

If you want to learn all you can about testing anything in your Django App, see my tutorial at DjangoCon. It’s on September 5th, it’ll be 3 hours long and so far with seven sign ups it will be very hands-on.

Here’s what I think I will cover, but I may change this depending on what the audience wants:

  • Testing issues
    • ask people to fill out etherpad with issues they’ve run into
    • ask someone to rank them in order of complexity
  • List an outline of topics
    • post them on etherpad
    • have people + them if they are interested
  • Testing overview
    • We started in late 2009 early 2010
    • Our largest project has 2500 tests
    • Our next largest has 1100
    • We have pretty good coverage
  • How testing works in Django
    • I’m not 100% sure on this
    • Test runner setups up a new database
    • Test runner finds and runs tests
    • Tests run class setup
    • Test runs each test in a test case
      • Load fixtures
      • Tests run setup
      • Tests runs the test
      • Tests runs teardown
    • Tests run class Teardown
    • You get an F if you’re bad and a . if your not.
    • Now that you know it, you can hack it.
  • How we’ve hacked testing
    • 2500 tests is a lot
    • We no longer recreate the database when you run the test suite
    • In each test case we just load the fixtures once.
    • We rearrange the tests so things with the same fixture set run together
  • Testing tools that we use at Mozilla
    • nose/django_nose
    • nose plugins
      • nicedots
      • progressive
    • coverage
      • git + whatchangedpy
  • Testing everything, no excuses
    • 100% Coverage isn’t important
    • 80% is nice
    • Good coverage on tricky things is important
    • Some coverage on everything is important
    • External
    • If you start depending on APIs, Search or different tools you need to be able to test for them.
    • Writing these test cases will take less time than this tutorial
    • It will save you so much headache in the future.
    • The same headaches you save yourself by writing “normal” tests
    • Mock easy things
      • use a decorator on any test/view that might use redis
      • if redis isn’t setup, use the mock client
      • mock client doesn’t support everything,
        • just what I need to get my tests running -
        • feel free to extend it if you use it
      • Testing Redis
    • Setup/Teardown for complicated tools
      • Good for search and APIs
      • Raise SkipTest (nose) if the developer doesn’t want to run these tests
      • Non realtime tools
        • Testing Sphinx search
        • SetupClass
          • load fixtures
          • run indexer
          • run server
        • Sphinx server now available for all tests in your test case
        • Teardown
          • stop server
      • Real time tools
        • Nicer, data can be added in post_save signals or elsewhere in your app
        • Testing LDAP
          • Setup
            • Remove LDAP files
            • Load an ldif
            • Start slapd
          • Your code can now touch LDAP
        • Testing ElasticSearch
          • We leave ES running all the time.
          • Setup
            • Checks for ES support or SkipTest
            • Deletes index
            • Creates index
          • You can now read/write to ES
          • Teardown
            • Delete’s index
    • Fixtures
      • Fixture Magic
      • Model Maker
    • pitfalls
      • dates
      • using PDB