Adopting good TDD habits is tough at first, and productivity will inevitably decrease while you’re getting your head around the cycle. Also, spending so much time testing and refactoring obviously takes more time than just mashing something into production because it “works”. Because of this, adopting TDD is often met with resistance from delivery managers, and this post is all about proving to them that TDD is worth it in the long run :).
Let’s remind ourselves of the TDD cycle:
1. RED – write a failing test
2. GREEN – make the test pass as simply as possible
3. REFACTOR – essentially, make it look nice
Step 2. ensures that we almost always have working, shippable code. Of course, we always have more functionality to add, but all code committed to version control WORKS. This means we can completely change up the way we release code.
This story will sound familiar to many readers:
– A change is required to the software.
– Users are told that they must wait a few months, as releases are infrequent.
– Developers start working on the new requirements, complete the work within a week or two (for example) but code must wait for the release a couple of months later before it can actually be deployed to production.
– Code must go through “testing phase” where defects are raised a few weeks after developers have finished working on it and moved onto the next piece of work; fixing these requires them to refresh their memories as to how the code works.
– A few developers will stick to fixing defects, while the rest of the team will move on to work on the new requirements. The ones that stayed back will then constantly be playing catch up.
…repeat ad infinitum
TDD has the potential to change all this, in the following ways:
– If our code is always in a shippable state, then the decision of when to release is entirely up to the business.
– If we can release more frequently, we have fewer changes in each release which reduces risk. This also means developers can learn and improve code faster, outlearning the competition (it is much easier to roll 1 change back than 100)
– Users can have their requirements fulfilled much more quickly, there is no need to wait for months and have millions tied up in “work in progress”.
– If our code is continuously being tested (by definition, as it is driven through the tests), then there is no need for a separate “testing phase”, as defects are fixed instantly (or ideally not even raised!).
In short, TDD gets us closer to continuous delivery, and (if done correctly) encourages clean code, which is ultimate perfection (and who doesn’t want to be perfect?!). Clean code leads to code that is easier to change and reuse and your system will have a much longer, healthier life.