Three Development Desires
I have three desires about my development processes that will help me create high quality systems that directly address customer needs. These are three pretty non-controversial wishes, and I can’t imagine anyone not wanting all of them!
- I desire to be able to know what the code I’m about to write must do, and be able to prove that it does it unambiguously,
- I desire to know almost instantly if my most recent change broke something anywhere else in my system,
- I desire a way to keep my system clean, healthy, and easy to modify so I can keep up as the world changes around me.
Enter Test Driven Development
It just so happens I know of a set of practices that addresses each of the desires above. The practices are part of Test Driven Development (TDD), one of the several Agile Engineering practices to come from Extreme Programming. Taken together, they give me a great set of tools to develop systems.
Let’s look at how TDD addresses the points above:
Desire 1: TDD is the practice of writing an example of what your code is going to do before you write that code. Literally, you set your expectations about success before you write the code, expressed as a test of your future software. You write just enough code to make that one test pass, and you’re finished.
This process is repeated hundreds of times for every piece of software that goes into a system. At the end of coding, you’re left with hundreds of examples that document what your system does and with a system that demonstrably works.
Desire 2: Part of writing tests and code like this is you focus on making tests that run really fast. This is needed because you’re going to end up with hundreds of them, and if each one takes a tenth of a second to run, at a hundred tests you’re up to at least a ten second wait. You will learn how to write tests that run fast.
Because you have tests that run fast, you can run them frequently — like after every change. So let’s say you follow a process like this:
- run all your tests and see them pass
- write an example, implement it, and confirm it works through your test
- run all your tests again and see them pass
If a test were to fail, the only reason why it could have failed is that your latest change broke something. And fixing it is easy, since you just have to make the now-failing test pass again.
Desire 3: There are two pieces to meeting this desire.
The first is that the act of writing those examples allows you to get an understanding for how other programmers will use your code. Your example will be the first code anywhere using the code you’re about to write! If the objects or methods are poorly named, if there are too many parameters or if they’re in the wrong order, or a dozen other code smells, then now is the time to change your example to make your future code better. There is literally no time where changing that about-to-be-written code will be any easier than right now!
The second is to understand that design happens differently in a TDD’ed system. You write your example, you write simple code, and you make the test pass. Hurray! Now, you need to go back and examine the design of your system and bring it back to being simple. This is called refactoring, and it is an integral part of this process. Implementing the example adds new features to your codebase, and refactoring is when you add design to make your new code fit nicely into its new neighborhood. Both activities are critical to success.
Invitation
I hope this gave you a small taste of what TDD is. I have a github repo where I’ve worked through an example, making frequent commits with detailed explanations along the way. You’re welcome to grab that repo, rewind back to the first commit, and go forward through the thought processes. In fact, I’d love for you to do that, and then let me know how it went!
Summary
Admittedly, this was a whirlwind tour through a really complex subject. There are lots of resources on the internet that explain TDD in a lot more depth than this teaser article. I’ll also be publishing a lot more as I write each section of the course I’m constructing now. Follow me here, and you’ll find out when I post another chapter in this TDD journey.
