Contact Us

XP Reflections - Test Driven Development

This article is written by Dave Chaplin, an IT Consultant with 10 years experience. He leads and mentors teams of developers on agile .NET projects and has extensive experience in agile development techniques, particularly Test-Driven Development. Dave can be emailed at davechaplin@byte-vision.com.

Date: Thursday, September 16, 2004


This article reflects on experiences of leading teams who use the technique of Test Driven Development (TDD). It discusses observations made together with some practical advice for those considering embracing the technique.


The set of ‘XP Reflections’ articles are based on actual hands on experience in the field leading teams of developers doing XP.

When I state doing XP I’m not really referring to following precisely the out-of-the-box XP process. Like most projects the process was adapted to suit the specific project, culture and capabilities of the organisations in which it was used.

This article discusses the topic of Test Driven Development.

[Acknowledgements to Antony Marcano of http://www.testingreflections.com for the inpiration behind the 'reflections' phrase. His site is well worth checking out.]

Benefits of TDD

In my opinion Test Driven Development is the greatest asset to come out of the agile movement. Significant quality and productivity gains are made by using TDD. Hence it is very rapidly spreading through development circles.

TDD speeds development by decreasing the time taken to regression test code in orders of magnitude. For example, on a previous assignment we could exhaustively regression test 45,000 lines of code (4 people – 18 months) using around 600 tests in 48 seconds.

With TDD repeat bugs are eliminated.

Before learning TDD it is like owning a car and always driving around in fourth gear when in fact it has five. Then someone comes along and shows you how to use fifth gear (TDD). The journey becomes smoother and faster. Considering going back to continued use of fourth gear is futile.

Every developer who I have trained in TDD techniques (about 25) continues to use TDD for their development effort today.


The technique provides a win-win for both management and developers. Managers obtain a comfort factor that the each release of the application will have high quality. They are spreading TDD as they move from company to company. Having ‘seen the light’ in one organisation they are keen to turn the switch in another.

Developers no longer have to code in fourth gear when they know fifth. Developers coding using TDD would prefer to code with others who have also learnt TDD. Otherwise they are dragged back down to fourth gear. ‘Can I show you how we can work quicker and enjoy it more?’

Is it new?

TDD aligns itself with the best practice of ‘Test Automation’. Basically, do lots of testing, do it often, and make it darn quick to do. This then ensures it is fast, exhaustive and 100% repeatable.

However, the problem in the past has been that the best practice of Test Automation has normally* only been adopted at the functional level by professional test teams after developers have released a version ready for testing. Professional testers have then used tools like WinRunner, Robot, and more recently OpenSTA.

[*There are some organisations who have conducted Test Automation at the development level, but it is certainly not common.]

So, whilst TDD is new in terms of its branding, essentially it just brings the best practice of Test Automation to the development level. We all should have been doing this for years anyhow!

Some could argue that TDD is different to traditional unit testing in that the tests are written before the code. This is true, and it helps to ensure the design is testable. But, good designers should design systems that are testable. Either way, you get to the same result.

TDD fills the gap

Developers have never really embraced testing before shipping software for testing. Developers like to create, and find testing their own code incredibly dull – so they don’t do it.

Some ad-hoc testing gets done in development, but it is rarely exhaustive, usually manual, and applied at the functional level – testing from the front end of the application.

Occasionally a developer might build a test harness which they can use to test components built, but this is usually a windows form they have knocked together and again requires manual testing.

Manual test harnesses are step closer but they are certainly not fast, not 100% repeatable, and not exhaustive. Also, the tests are only documented in the developers head, and they are the only person who knows who to use the test harness. This is not ideal.

TDD uses standard industry wide tools that are freely available, an example being NUnit for .NET development.

Implementing TDD – some practical advice

Having discussed the advantages of TDD and why it is becoming increasingly popular here’s some practical comments regarding implementation:

  • TDD is counter-intuitive for traditional developers. They initially think that it cannot possibly be quicker to write twice as much code. [Typically test code size is the same as production code.] In my experience the only way to convince them is to ask for their trust, and demonstrate it in a real world scenario. Once they see they will their test times reduced and code quality increased it will simply click.

  • TDD in the hands of novices can result is huge messes being made. The options are to hire a mentor or suffer the same mistakes again. You will achieve your objective twice as quick with a mentor.

  • Learning TDD takes time:
    • Developers can learn how to use standard unit testing tools in an afternoon. It can then take them around three months (with a good coach) before they then learn what to test and how to write a good test.

    • After the three month period of learning how to write good tests it will take an experienced OO developer and designer (5+ years) a further 6 months before they become good at designing systems for testability.

    • After about one year a good OO designer will have testability embedded in their thinking to a point as which it is instinctive.

  • The quality of the test code needs to be of production quality. This is often overlooked and maintaining test code as the application code expands can become cumbersome.

  • TDD is used in agile methods that make use of refactoring. It is not advisable to even consider refactoring without a full suite of exhaustive tests.

  • Whilst tests are required at the unit level, it is important to have tests at the functional level. These then provide a safety net when refactoring ‘below the bonnet’.

  • In terms of developer capability my view is that TDD requires very good developers who have at least 5 years development experience in an OO language combined with knowledge and experience of using design patterns. TDD is certainly not for hackers.

  • Applying TDD principles to existing projects is hard. It is likely that the existing code base has a design which is untestable. This means the level of decoupling and interfaces are not sufficient to be able to inject tests at any point in the code base. Retrofitting tests to existing systems can be a real pain. It is much easier to start with TDD in mind than it is to retrofit it afterwards.

  • For reasons raised above, for those embracing TDD for the first time it is advisable to start with a new project. Perhaps a small one.

  • It is true that considerable gains are made using TDD in iterative development projects. Since quality is higher there is no stepping back before moving forward after each test cycle and release. In one shot developments it is still beneficial to use TDD since the development effort itself is still iterative and as the application evolves significant gains are made in the ability to regression test previous work in seconds.

  • Whilst TDD produces massive productivity gains, bear in mind that its tests are applied at the functional level – not the business. You could build yourself a very fast development capability like a well oiled machine. But if your business requirements are wrong, and you’ve been driving up the wrong road, the application is worthless. Getting to the wrong place in a broken car or a fighter jet is the same. It is still the wrong place.

Closing comments

TDD is provides significant quality and productivity gains and is a win-win for managers and developers.

It is however hard to do, and it is advisable to start small for the first time and if possible hire a mentor.

Other Articles

Test Driven Development (Dec 2003)
The Losers Olympics (Sep 2003)
Making Projects Succeed: Part 1 - Measurable Business Goals (Sep 2003)
Pitfalls In Software Development (June 2003)
Extreme Web Architectures - Testing Web Applications In Seconds (June 2003)
Pair Programming and Quad Programming - From Experience (June 2003)
Making Extreme Programming A Success (April 2003)
Contractual Test Driven Development (TDD with DBC) (April 2003)
Moving To XP (Feb 2003)
Maximising Development Productivity (Dec 2002)
Writing Automated Browser Tests Using NUnit and IE (Oct 2002)
Mitigating Requirements Risk With Agile Practices (Oct 2002)
10 Tips for Successful Team Leading (Oct 2002)
Developing Automated Using Tests Using NUnit 2.0 With VB.NET (Sep 2002)
Quality By Design - Part 1.doc (May 2001)
Quality By Design - Part 2.doc (May 2001)
Quality By Design - Part 3.doc (May 2001)

Other Resources


Extreme Programming


Agile Modelling

All content © Byte-Vision Limited 1997 - 2004