Test-Driven Development with Python, 3rd Edition

Chapter 7. Working Incrementally

Now let’s address our real problem, which is that our design only allows for one global list. In this chapter I’ll demonstrate a critical TDD technique: how to adapt existing code using an incremental, step-by-step process that takes you from working state to working state. Testing Goat, not Refactoring Cat!

Small Design When Necessary

Let’s have a think about how we want support for multiple lists to work.

At the moment, the only URL for our site is the home page, and that’s why there’s only one global list. The most obvious way to support multiple lists is to say that each list gets its own URL, so that people can start multiple lists, or so that different people can have different lists. How might that work?

Not Big Design Up Front

TDD is closely associated with the Agile movement in software development, which includes a reaction against “big design up front”—the traditional software engineering practice whereby, after a lengthy requirements-gathering exercise, there is an equally lengthy design stage where the software is planned out on paper. The Agile philosophy is that you learn more from solving problems in practice than in theory, especially when you confront your application with real users as soon as possible. Instead of a long up-front design phase, we try to put a minimum viable product out there early, and let the design evolve gradually based on feedback from real-world usage.

But that doesn’t mean that thinking about design ...