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!

Fear of fixing code

A while back I was working on a task of retrospectively documenting a project written a couple of years back. Whilst I was going through the code building up my understanding of it I came across a number of code smells. Nothing major fortunately but, things like, print errors to System.out rather than using loggers, code that appeared to no longer be required, things that should be refactored for clarity etc. Although this isn’t great, it’s no surprise and I’ve seen many projects like this in the past. Also, developers will have come across issues with my code written before I appreciated the benefits of automation.



The most painful part with these issues was the fear of breaking the product if I addressed the issues.

I had this fear because the project had no automated tests to speak of which meant the only way of verifying whether things were still working would be to manually test the code myself which isn’t the best plan or schedule some time in with QA. Neither of these are an option because of cost, so because of this the code was left as is.

The trouble is, this will only get worse and over time the code will begin to rot. Changes will take longer, more manual testing is required etc. and all this costs time and money.


When writing any code whether it is new or adding to existing code, make sure that it has automated tests to prevent the rot and reduce the fear of making changes that can be verified using automation. You don’t have to use TDD, however, once you get the hang of it, it will certainly make writing tests a lot quicker. I recommend starting as soon as you can, to understand the ways in which to write unit and integration tests and you will soon find comfort that whenever you need to refactor code, add functionality etc. you will have the security blanket of your automated tests to keep you calm!