TDD – Small Leaps Of Amazingness

Test Driven Development is all about small verifiable steps. You write a little test, you write a little code, you get a nice green bar, you reshape the code, and that bar stays green. There are plenty of things that Test Driven Development gives you such as:

  • Low Level Documentation
  • Loosely Coupled Design (when performed well)
  • Confidence to Fearlessly Refactor
  • Higher productivity with less time spent Debugging
  • Exceptionally high Test Coverage

The benefits of Test Driven Development are well documented. I want to talk about what I'm calling "Small Leaps Of Amazingness". I recently ran a Randori with two other developers in which we solved Roman Numerals problem, I was the only developer in the group that had completed this problem before.

It was really interesting to watch and to question decisions the other developers made. As you would expect, neither of them could see a clear path to the end goal. That is to say they didn't have one Large Leap of Amazingness in which they mentally solved the problem. It was the act of performing Test Driven Development that led them to a solution. Every time they had to fix a new test, they would fix it in the easiest way possible then look for refactoring opportunities. They took Small Leaps Of Amazingness. They could find solutions to smaller parts of the puzzle, parts of the puzzle that would not have been visible were it not for the Test Driven Development approach they were taking.

Small Leaps of Amazingness So what am I driving at? To solve a problem, especially a big problem, it generally takes a great deal of thinking and a great deal of trying. It's always tempting to try to solve the complete problem too early, or rather to take one Large Leap of Amazingness. I don't think it would be controversial to say that trying to make large leaps often ends in badly. In fact it probably looks a bit like this:

Failed Large Leaps

Test Driven Development forces us to attempt the smallest leap we can possibly make, it forces us to make Small Leaps of Amazingness . And it's not just a matter of abiding the 3rd rule which states " You are not allowed to write any more production code than is sufficient to pass the one failing unit test ", it's also about picking the right test to fix next.

The right test is the smallest leap we can find. I find this the hardest part of Test Driven Development, for example, in the Roman Numerals problem I now always start with conversion of 0, 1, 5, and 10. However this wasn't my instinct the first time I tried this Kata, nor was it the instinct of those who had not tried it before in the Randori. They assumed it would be simplest to start 1, 2, 3, 4, 5 etc. This is what we found started to happen:

Should be there by now

One of the most interesting ways to make a test go green, is to Ignore the test. When I start to think "I should be there by now", it usually indicates I've missed a test, and that I am trying to make a leap that is too large. In these circumstances I Ignore the test, and instead try to identify a simpler test.

It's not always that the test isn't simple enough. Sometimes it's because enough attention hasn't been applied to the refactor stage and Code Smells have started to arise. In these cases, having Ignored the test and thus reentered the refactor stage, refactoring can take place to get rid of the Code Smells. In many ways I expect Code Smells to arise when performing Test Driven Development because " You are not allowed to write any production code unless it is to make a failing unit test pass ". That doesn't mean we have an excuse to allow the Code Smells to persist. If we allow the Code Smells to persist we will become blinded by their odorous stench such that we cannot see our way to fixing the next simplest test.


  • Test Driven Development forces us to make Small Leaps Of Amazingness
  • Small Leaps Of Amazingness are easy and quick to solve
  • When a Leap Of Amazingness doesn't seem Small, it isn't a Small Leaps Of Amazingness, and it probably won't be Amazing
Posted in Test Driven Development