DjangoCon 2011 – Testing: The Developer Strikes Back

Next up is “Testing: The Developer Strikes Back” by Sandy

“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!

You can view Sandy’s talks at

Updates below:


Tests don’t replace good documentation


When writing tests, pretend that you’re a user and test against what they would be doing.


How do you train your developers between “My test suite passes” and “My test suite actually tests my code”?

Make sure your developers look at the code. Break the code and see if the code still passes. Trying to break the test suite.


@sandymahalo talk over now. Fantastic speaker, answering questions now.


How to sell testing at your Django shop

  • Saves money
  • Saves development time ($$$)
  • Happier developers
  • Saves on QA time ($$$)
  • Gives you more confidence in your code


Staging environment should be identical to production (or as close as possible)


Code should not be written in such a way that it won’t work (at least in some fashion) if a certain service or infrastructure fails


Service unavailable shouldn’t mean that your site is unavailable.


Developers need to think outside of their dev instances. What happens to the code under condition X when it interacts with service Y


Fixtures are great for loading data required to bootstrap your application. ObjectCreator classes for models that change frequently.


Testing a virgin codebase:

  • Test Driven Refactoring
  • Broadly test each app. Drill down testing afterwards
  • Require unit tests for all code going forward
  • Reserve time/points to clear out “test debt”
  • Establish a good foundation to build on
  • Every bug is two bugs: One in the code that broke, and one in the test that failed to detect it
  • Implement Continuous Integration (CI) to monitor coverage


Sometimes testing can difficult because it can depend on your environment.


Make a game out of testing with


Testing allows for faster iterations and deployments with more confidence. Less 2AM fires that you have to fix.


Tests are not “set it and forget it”. Tests always need to evolve as new functionality is added


Well-tested code is a good medium. It’s more realistic, practical and allows for a more individual “style” in the dev cycle


Test Driven Development (TDD) doesn’t really exist in real life. Deadlines, non-technical management, poor planning, competing obligations get in the way.


If the tests aren’t easy to write, your functions are too difficult. Try to refactor if possible.


“Writing tests can improve coding habits”. Smaller, more module code is testable, 200-line functions aren’t


How do I test cache?
You need to know and understand how your modified application behaves when it interacts with a cache that was generated by your application in a previous state.


Don’t take 3rd party APIs for granted. Even Facebook goes down from time to time. Have tests to cover what happens when that API is down (or changes)

17.31 can be used to mock an actual object.


Using a ObjectCreator class makes the supporting code for your test more loosely coupled and easier to write


Aggregating certain test methods that are used throughout the entire project are fine to put in a at project root, just don’t put all tests in there.


Example project layout



Have multiple test files, don’t aggregate all tests into a monolithic file named


Separate code and service/infrastructure testing.


Separation should exist between the testing of:

  • Business logic
  • Datastores
  • 3rd party APIs


Within a Django project each app needs its own test module.


What is “Unit testing”

A method by which individual units of source code that are tested to determine if they are fit for use.


“Testing: It’s hard to do (right)”. Tests are living code and evolve over time


Ah, its Sandy Strong (@sandymahalo) from PyLadies


First slide looks like it’s straight from Awesome


Sandy taking the stage. No idea what her last name is.