The Test Driven Development (TDD) mantra has been around for years. Write a test that fails, write the code that makes it pass (and no more), rinse and repeat. Many developers resist TDD or try and fail to gain any benefit from it, but when performed correctly, in a supportive environment, its benefits become clear.

The first thing you will notice is a lower number of defects. A substantially lower defect count is noticed during active development. Why so? Because when somebody writes new code, there is a pretty good chance it will break something in the existing codebase. But with TDD, the tests will also break, making it much easier to find and fix those defects. If you iterate often and your regression tests are fast then defects are spotted in near real-time and nobody will want to leave a build broken for long, especially with their name on it.

As an extension from this, TDD gives us the confidence to innovate. With your test suite set-up and performing correctly, a potentially frightening piece of refactoring can take place with confidence. For example, the Amaxus Web CMS versioning system was able to be developed outside the main code line because, even though the entire feature set impacted on stable, existing code, the tests in place gave the developers the confidence to merge their code in, without introducing instabilities or errors.

This confidence is what gives us the opportunity to innovate and expand our Web CMS feature set now and in the future.

[Ignore: Technorati claim code: ZPQC4KV5NKRQ]