CHAPTER 22
Fast Tests, Slow Tests, and Hot Lava
The database is Hot Lava!
—
Casey KinseyRight up until
Chapter 19 ,almost all of the “unit” tests in the book should perhaps have
been called
integrated
tests, because they either rely on the database, or they use the
Django test client, which does too much magic with the middleware layers that sit be‐
tween requests, responses, and view functions.
There is an argument that a true unit test should always be isolated, because it’s meant
to test a single unit of software.
Some TDD veterans say you should strive to write “pure”, isolated unit tests wherever
possible, instead of writing integrated tests. It’s one of the ongoing (occasionally heated)
debates in the testing community.
Being merely a young whippersnapper myself, I’m only part way towards all the sub‐
tleties of the argument. But in this chapter, I’d like to try and talk about why people feel
strongly about it, and try and give you some idea of when you can get away with mud‐
dling through with integrated tests (which I confess I do a lot of!), and when it’s worth
striving for more “pure” unit tests.
Terminology: Different Types of Test
Isolated tests (“pure” unit tests) vs. integrated tests
The primary purpose of a unit test should be to verify the correctness of the logic
of your application. An
isolated
test is one that tests exactly one chunk of code, and
whose success or failure does not depend on any other external code. This is what
I call a “pure” unit test: a test for a single function, for example, written in such a
way that only that function can make it fail. If the function depends on another
system, and breaking that system breaks our test, we have an
integrated
test. That
397