In part one of the Clean Coders episode on Test Driven Development, Uncle Bob lays out the three rules of TDD, and then frames his “hard sell” of TDD within the framework of the most common protestations against it. (It’s a pretty entertaining episode as the protestions are made by Uncle Bob channeling his inner Vulcan.)

First, the three rules:

1) Write no production code until you have written a failing test.
2) Write only enough of a test to demonstrate failure.
3) Only write enough production code that is necessary to make a test pass.

These rules may seem like a huge shift for developers who’ve never practiced TDD before, and the argument that might immediately jump out is the seemingly disruptive flow of all the context switching between test, code, test, code, etc… It looks as if writing all those tests will slow you down in the short run. But in my experience, the TDD flow is just a different kind of flow- like a new style of swimming stroke. Once you get comfortable with it you can write code just as quickly as you did in the past.

As Uncle Bob explains through the rest of the episode, the real time savings of TDD adds up exponentially over the long run.

The most tangible benefit is reduced debugging time, as a well-developed test suite will eliminate most bugs before they happen. And if bugs do pop up, it will be much easier to track it down.

Uncle Bob covers the BIG time savings of TDD in a series of topics that are very closely intertwined: Decoupling, Eliminating Fear, Trust & the Courage to Change.

When you test drive your code it often forces you to build a decoupled app so that you’re able to test each part of it. These decisions lead to a better overall design and architecture of your application. A decoupled system is one that is more *“flexible, scalable and maintainable"— and when you have complete faith in your suite of tests then you can flex, scale and maintain that code without fear. You can clean up old code, refactor ugly code or swap out modules of your application, and if anything goes awry then your tests will immediately let you know what happened so that you can fix it and continue moving forward.

Without a suite of tests that you can trust, then each "upgrade” to your system could be a stressful affair instead of something to be excited about.

(Hmm, maybe Apple should release a test suite for users that we can run before an OS upgrade? That would certainly make it less stressful)