As an agile tool, Test Driven Development is still waiting for its big breakthrough. TDD evangelist David Nicolette explains why he uses it as his own default approach.

Although the tools have been around for fifteen years now, TDD has never become the normal way of building code across the industry. Rather it has become a sort of ”Think Different” movement, embraced by the leaders in the advancement of software development practices. One of the standard bearers is Dave Nicolette, an independent software and method consultant from Dallas and a popular Lean and Agile blogger.

TDD may have become something of a buzzword in trade blogs and magazines, but still Dave Nicolette has only observed a small increase in actual interest and acceptance by developers in the software industry over the past 10 years. Most developers have heard of it, but have never tried it and most of those who have tried it have never made it their default method of building code. In Nicolette’s eyes, the majority of people who earn a living by writing software seem content to use techniques which, as he puts it, ‘create unnecessary extra work, misalignment with customer needs, defects, needless complexity, and delayed delivery’.

A new approach is needed

”There appears to be a general lack of awareness that the situation could be better,” Dave Nicolette says. ”TDD is not the only way to produce good results, but many developers evidently do not use any techniques – neither TDD nor anything else – to ensure their solutions are clean, accurate, and robust.”

For this to change, Dave Nicolette thinks that universities must teach students to build software in a new way. Nicolette is positive about the school where his son studies programming, as students here are expected to make the provided tests pass as well as extending the test suite to cover all necessary cases. They are also encouraged to collaborate rather than compete.

”I would like to see this approach become normal in schools, as it prepares students to do real work properly after graduation. Perhaps one day we will no longer have to re-train every university graduate before he or she can become effective on the job; or perhaps I am an optimist,” Nicolette says.

Several benefits

According to Nicolette, the value proposition of TDD is the same as it has always been: it helps us produce software that aligns well with customer needs, has relatively few defects, is understandable and maintainable, and is no more complicated than the problem requires. TDD also enables emergent design, which helps programmers to avoid over-engineering or “gold-plating”. It also enables flexibility in embracing change and meeting challenging time-to-market requirements.

”Code that lends itself to automated testing tends to be cohesive and loosely coupled. Benefits of this include ease of code isolation, separation of concerns, extensibility and maintainability. These characteristics lead to solutions that have longer production lifetimes and lower cost of ownership than solutions developed using traditional methods. We also avoid the opportunity cost of extended debugging and ‘hardening’ of solutions, in that development teams can turn their attention to a new project more quickly than is possible with traditional methods.”

An automated test suite may serve as an early warning system for regressions and a safety net for modifying the production code—including both functional changes and structural changes (refactorings). Without it, there is a high probability that any modification will result in new defects that cannot be detected in a reliable way before the code goes live.

Seeing what the system actually does

Because well-defined automated test suites unambiguously and completely describe the behavior of a system, TDD reduces the quantity of technical documentation that is usually necessary to support a solution. High-level architectural diagrams and a context diagram are often the only documentation artifacts needed.

”This has benefits for production support personnel as well as for new team members who need to learn an unfamiliar code base. They can easily see what the system actually does in its current version, rather than depending on an abstract description of what the system was intended to do as of the time it was first designed,” Nicolette says, and continues:

”On a personal level, the value proposition is simple: TDD makes the developer’s life easier. We chose a career in software development because we enjoy solving problems and creating useful, elegant software. Using TDD, we are able to spend most of our time doing those things. Using traditional methods, we spend most of our time debugging. Most developers find debugging to be less interesting than creating or improving systems. I am too lazy to spend time debugging problems that I can easily avoid creating in the first place. I am too lazy not to use TDD.”

”It is always risky to predict the future, but I think it may be safe to say that people will continue to advance these ideas, as they have done since the 1960s. I look forward to the day when someone invents a better way to build software than TDD. Until that day, I will continue to use the practice as my own default approach.”