Why adopting Test Driven Development?

Write a test that covers a use case or some functionality, then let the test run and fail. Once this is accomplished write as little code as possible so that the test passes. After the test passes turn the code into clean code; meaning refactor, simplify, adhere to convetions, etc. Done? …repeat that cycle. That approach is called Test Driven Development (TDD) according to Kent Beck. But why are we doing that?

Well, I would say the right question is why are we not always do this or why don’t we always have done it that way. Test Driven Development is a very efficient and productive way of implementing software. This matters as software development doesn’t end in itself, software development serves a business, at least it should.

TDD leads to change in the way we design software. We think of what change we need to do to let the test pass. The risk of waste is quite low with that way of working. When you follow Test Driven Development your code is always working. Otherwise your tests fail and a feedback loop triggers the team. Something like writing code and throwing it over the fence or writing code not knowing whether it does what it should or not doesn’t happen with Test Driven Development. TDD encourages a very modular way of developing software. Thus it is easier to navigate in existing code when implementing new value or debugging issues.

Doesn’t Test Driven Development take time and resources?

As already mentioned, with TDD you only write code that is really necessary to pass the test. Doing that, you avoid waste compared to other approaches when you write code based on assumptions. Without scientific measures my intuition say that should be faster. Remember, if you gold plating (writing more code than actually needed and consider edge cases) you’re not doing TDD. 

Writing code that is very modular might not always save time compared to writing non-modular code. It should make you faster on the long run though. Of course you can achieve very modular code without TDD as well. TDD is just supporting and encouraging it.

As you follow simplicity with TDD, you will save time you’d otherwise spend for re-work. That time you can invest in something more valuable. The risk of building up debt in your code base is lower if you just add minimal changes to pass existing tests.

So, there is more effort before actually implementing the desired value. Developers actualy spend time thinking through the value to be delivered and the functionality to be implemented. Doing this is beneficial as thoughts get structured and clearer which will result in better code quality and the desired value.

–

We want to delivery as much value as possible in a given time or budget. I personally think TDD brings us close to that target.