Month: May 2015

How to get a team ready for TDD on their projects

TDD is great! I’ve found it a brilliant way of thinking about how my code is put together and how to make it testable from the outset, however, for a lot of developers there are a few hurdles to overcome first.


The biggest two I would say are:

1) Why should I bother?

2) How to do it?

Why should I bother?


In addition to the benefits of writing unit tests in the first place, TDD brings additional benefits to the table. Here are a few below:

– Force the developer to think about what the code is meant to be doing.

– Forces the developer to think about the dependencies in the code.

– Prevent tight coupling of dependences.

– Provides the developer with a security blanket when they need to make changes to the code at a later point, i.e. they can make changes and verify they haven’t broken the rest of the system.

– Because the developer has to write tests before writing any code it forces the code to be testable all the time. Removing the issues around the code being untestable.

“Force” might sound like a harsh term, however, it does mean that the code that comes out of this process will be better for it. There is less opportunity to avoid challenges like dependency management and therefore improvements naturally follow when using TDD.

How to do it?

I have heard this statement many times from developers and management. “Okay, I understand the point of TDD now, but my projects are too complex to start using it

This is a common response from many developers particularly on projects that are long established with code bases that don’t have any tests in place. This results in code that is already very difficult to test and therefore, starting TDD is even more difficult. Another issue I have come across is in teams that aren’t writing code day in day out and therefore their coding skills are already starting from a bit of a rusty position.

Today, I came across a great article called “Kata – The only way to learn TDD” which presented a good solution to the problem. Rather than trying to get developers used to using TDD in their own code, get them used to following the principles with some simple challenges. This also has the benefits of getting developers used to their IDEs as well, learning shortcuts and speeding up development.

So, a great way to get going with TDD is learn about the basics of Red, Green, Refactor and then get practicing with some simple code kata challenges. These will hone your TDD skills as well as increasing your knowledge of your IDE.

Time to give it a go. Good luck!