Test-Driven Development with Python, 3rd Edition

Chapter 4. What Are We Doing with All These Tests? (And, Refactoring)

Now that we’ve seen the basics of TDD in action, it’s time to pause and talk about why we’re doing it.

I’m imagining several of you, dear readers, have been holding back some seething frustration—​perhaps some of you have done a bit of unit testing before, and perhaps some of you are just in a hurry. You’ve been biting back questions like:

• Aren’t all these tests a bit excessive?

• Surely some of them are redundant? There’s duplication between the functional tests and the unit tests.

• Those unit tests seemed way too trivial—​testing a one-line function that returns a constant! Isn’t that just a waste of time? Shouldn’t we save our tests for more complex things?

• What about all those tiny changes during the unit-test/code cycle? Couldn’t we just skip to the end? I mean, home_page = None!? Really?

• You’re not telling me you actually code like this in real life?

Ah, young grasshopper. I too was once full of questions like these. But only because they’re perfectly good questions. In fact, I still ask myself questions like these—all the time. Does all this stuff really have value? Is this a bit of a cargo cult?

Programming Is Like Pulling a Bucket of Water Up from a Well

Ultimately, programming is hard. Often, we are smart, so we succeed. TDD is there to help us out when we’re not so smart. Kent Beck (who basically invented TDD) uses the metaphor of lifting a bucket of water out of a well with a rope: when ...