Chapter 6. Improving Functional Tests: Ensuring Isolation and Removing Voodoo Sleeps
Before we dive in and fix our real problem, let’s take care of a couple
of housekeeping items. At the end of the last chapter, we made a note
that different test runs were interfering with each other, so we’ll fix
that. I’m also not happy with all these time.sleeps peppered through
the code; they seem a bit unscientific, so we’ll replace them with something
more reliable.
Both of these changes will be moving towards testing “best practices”, making our tests more deterministic and more reliable.
Ensuring Test Isolation in Functional Tests
We ended the last chapter with a classic testing problem: how to ensure isolation between tests. Each run of our functional tests was leaving list items lying around in the database, and that would interfere with the test results when you next ran the tests.
When we run unit tests, the Django test runner automatically creates a brand new test database (separate from the real one), which it can safely reset before each individual test is run, and then throw away at the end. But our functional tests currently run against the “real” database, db.sqlite3.
One way to tackle this would be to “roll our own” solution, and add some code
to functional_tests.py which would do the cleaning up. The setUp and
tearDown methods are perfect for this sort of thing.
Since Django 1.4 though, there’s a new class called ...
Get Test-Driven Development with Python, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
