Test-Driven Development with Python, 3rd Edition

Chapter 5. Saving User Input: Testing the Database

So far, we’ve managed to return a static HTML page with an input box in it. Next, we want to take the text that the user types into that input box and send it to the server, so that we can save it somehow and display it back to them later.

The first time I started writing code for this chapter, I immediately wanted to skip to what I thought was the right design: multiple database tables for lists and list items, a bunch of different URLs for adding new lists and items, three new view functions, and about half a dozen new unit tests for all of the above. But I stopped myself. Although I was pretty sure I was smart enough to handle coding all those problems at once, the point of TDD is to enable you to do one thing at a time, when you need to. So I decided to be deliberately short-sighted, and at any given moment only do what was necessary to get the functional tests (FTs) a little further.

This will be a demonstration of how TDD can support an incremental, iterative style of development—​it may not be the quickest route, but you do get there in the end.¹ There’s a neat side benefit, which is that it enables me to introduce new concepts like models, dealing with POST requests, Django template tags, and so on, one at a time rather than having to dump them on you all at once.

None of this says that you shouldn’t try to think ahead and be clever. In the next chapter, we’ll use a bit more design and up-front thinking, and show how ...