Test Driven Development

Test Driven Development (TDD) can seem completely counterintuitive. Testing before development? The tests won’t even compile! Also, does this mean that you would no longer need QA resources, since the testing would already be done? Let’s first take a look at the standard TDD process.

1. The Business and QA define the Acceptance Criteria (AC)
2. Developer creates unit tests prior to development (and yes, they typically won’t compile)
3. Developer codes until all unit tests pass

Pros

There are quite a few advantages of TDD:

• More accurate requirements – When acceptance criteria are created prior to the start of development, developers have a clear target and will more likely succeed.
• More disciplined development planning – Developers are understandably eager to begin development, but creating unit tests at the outset helps them take a few moments to think through a sound development approach.
• Higher code quality – Catch more bugs before they make their way into QA and (heaven forbid) a production environment.
• More relevant unit tests – If you create unit tests prior to development, you create them to the requirements. If you create them after development, developers sometimes create them to pass what was built, which may not be aligned with the actual acceptance criteria.
• Comfort – 100% unit test coverage provides a certain level of comfort with the system stability.

Cons

The main disadvantages of TDD include:

• More work – 100% unit test coverage does not come free. Time must be spent to create the unit tests.
• False sense of security – Some people feel like they are bullet-proof if they have 100% unit test coverage, when in fact unit testing in no way constitutes comprehensive testing. Unit tests merely tell you that each individual piece of the application works. Whether they all play together properly is the domain of integration tests, acceptance tests and manual testing.

Too much hassle?

Unit tests are more work, but I have found that teams soon become adept unit testers and are able to knock them out very quickly. In fact, we recently reached the end of one of our large projects and had a post mortem review. I was expecting to hear some grumbling about the 100% unit test coverage requirement, but was somewhat surprised to hear developers praising the approach. They claimed that they are not only pretty quick at knocking out the unit tests, but also have found value as they have planned a bit better and also exposed bugs in their code prior to release to QA.

I highly recommend 100% unit test coverage. Just make sure you provide plenty of opportunities for training and assistance with unit tests early in the project to minimize the added work load.

So does TDD remove the need for QA?

Even if your developers create integration tests (I recommend one per user story) in addition to their unit tests, there are still big advantages of what QA brings to the table. Whether it be creating and executing test cases aligned with the AC, end to end testing, load testing, performance testing, etc., you really can’t get this with unit tests and some integration tests. They also provide a vital “checks and balances” role, ensuring that developers have built to the AC.

Some teams go so far as to have their QA team automate all of their acceptance tests. Quick and comprehensive regression testing, right? Actually I have found this to be a disaster, as the effort is massive and the maintenance becomes increasingly onerous as the project goes on. Time spent by QA on automated testing definitely has diminishing returns. I have found that it is best to create and maintain a nice automated regression test suite based on the 80/20 rule, i.e. you can get 80% coverage of the application with the 20% of the tests. This can save serious time on manual regression testing, although automated testing should NEVER completely replace manual testing. Enhance and tweak your regression test suite over time based on new and changing features, but don’t let it grow out of control!