351 / 478
CHAPTER 18
Finishing “My Lists”: Outside-In TDD
In this chapter I’d like to talk about a technique called “Outside-In” TDD. It’s pretty
much what we’ve been doing all along. Our “double-loop” TDD process, in which we
write the functional test first and then the unit tests, is already amanifestation of outside-
in—we design the system from the outside, and build up our code in layers. Now I’ll
make it explicit, and talk about some of the common issues involved.
The Alternative: “Inside Out”
The alternative to “Outside In” is to work “Inside Out”, which is the way most people
intuitively work before they encounter TDD. After coming up with a design, the natural
inclination is sometimes to implement it starting with the innermost, lowest-level com‐
ponents first.
For example, when faced with our current problem, providing users with a “My Lists”
page of saved lists, the temptation is to start by adding an “owner” attribute to the List
model object, reasoning that an attribute like this is “obviously” going to be required.
Once that’s in place, we would modify the more peripheral layers of code, such as views
and templates, taking advantage of the new attribute, and then finally add URL routing
to point to the new view.
It feels comfortable because it means you’re never working on a bit of code that is de‐
pendent on something that hasn’t yet been implemented. Each bit of work on the inside
is a solid foundation on which to build the next layer out.
But working inside-out like this also has some weaknesses.
Why Prefer “Outside-In”?
The most obvious problem with inside-out is that it requires us to stray from a TDD
workflow. Our functional test’s first failure might be due to missing URL routing, but
323