“Code not tested is broken by design” - Jacob Kaplan-Moss

Every programming project has unique testing needs. It’s not always easy to understand what those needs are, or how to write tests that satisfy them. One of our goals as developers is to write tests that minimize failures in production that can cost our companies time, money, resources, and in many cases, hours of sleep!

Detailed Outline:

• Unittest organization strategies for Django projects
  • Delegation of responsibilities across suites
  • Creating modules and sub-modules that address
    • business logic, datastores (volatile and persistent), 3rd party APIs
    • network latency, concurrency, and race conditions
  • Test classes
  • ObjectCreator and Mock
• Fixtures - What they’re good for, what they’re not good for
• Dealing with increasingly complicated testing scenarios
  • Third-party API testing
    • Mock responses
    • Isolate to dedicated test module(s)
  • Getting bitten by caching
    • Model changes
    • Django code changes
• Improving coding habits through test writing
  • Contending with the reality that often development isn’t truly “test driven,” and how we can correct this.
  • 200-line functions vs. small, modular, testable code
  • Every bug is two bugs: one in the code, one in the tests.
• Testing a virgin codebase
  • Test driven refactoring
  • One file at a time - methodical approach very important
  • Going from 0 to 100% code coverage
• Where fixtures, sqlite, persistent datastores, and cache fit into testing
• Testing tools that you should know about
  • Nose <pypi.python.org/pypi/nose>
  • Coverage <pypi.python.org/pypi/coverage>
  • django-coverage <pypi.python.org/pypi/django-coverage>
  • Mock <pypi.python.org/pypi/mock>
• Graceful code degradation
  • Service unavailable shouldn't necessarily mean that your site is unavailable
  • Writing tests to anticipate worst case scenario, graceful failure/failover
• How to sell testing at your Django shop
  • Saves $$$: dev time, happy devs, qa time, confidence
  • Don’t check it in until it’s tested, and tests pass. Enforce this simple rule.
• Infrastructure
  • Testing things like cache, solr, rabbitmq as they relate to your project
  • Simulate network latency?
  • Databases and routers