The House of TDD

During the first week of my coding course at Makers, we were introduced to the idea of Test Driven Development (TDD). This idea puzzled me and so I spent a morning trying to understand it a bit better. In a video about Rspec and Ruby by Monoso, Brett says “So, we have our first failure, which is great. Always the first step in test driven development”. That seemed very counterintuitive to me. The idea that the first thing I should do is create a test that would fail and then — only then — write the few lines of code that would pass that test seemed strange. After all, shouldn’t we be learning how to code? Shouldn’t we be cracking on with creating classes of objects and the messages they would send to each other? Why bother creating test for something that doesn’t even exist?

Later that day, I used a metaphor to explain to a friend what TDD is. I compared it with building a house. Say you have an inspector that tells you what is wrong with the house you are building. You ask the inspector to check for walls and it replies “there are no walls”. You build a wall by piling up some bricks, but the inspector checks it and says “you forgot to put some concrete before laying the bricks”. Ok, so you do that. You ask for feedback again, and it’s all good. You move on to adding windows to your wall, but now the inspector says “Hmm, I can’t see any windows”. You build them, and he says “you need to make sure windows have glass”… you insert glass in the wooden frames. Inspection: all green now. Finally, you ask for a roof, and he says “it seems that rain is pouring straight to your living room”. You add the roof, but now “water is flowing through the walls and windows”, so you add gutters and a spout. All good now.

Granted that in a real world example you might not have an inspector available to check every single process, going through this hypothetical example provided an insight: what would happen if you were to build the whole house and then, only then, ask for an inspection?

The checks might be something like:

• “there are no walls”.
• “you forgot to put some concrete before laying the bricks”
• “can’t see any windows”
• “you need to make sure windows have glass”
• “it seems that rain is pouring straight to your living room”
• “water is flowing through the walls and windows”

Total nightmare! Where do you even start?

The House of TDD gave me a visualisation of the process, and also an insight into what might happen if you delay an inspection for too long. By now, TDD was a bit clearer. You create a test, watch it fail, and then go write the code. You do this even before writing your first line of code. In other words, the tests come first. And they come first not only chronologically — you write the test before writing the code that fixes it — but also logically — testing takes conceptual precedence.

In The House of TDD, then, the absolute first thing that you do is fail.

A life lesson, in a sense.