The problem is that, too often, people doing requirements gathering don’t think about testing. I’ve seen tons of untestable requirements, such as:

* The function shall be easy to use.
* The interface shall be intuitive.
* The customer shall be able to perform XYZ task with no training.

In each of those “requirements,” there is so much vagueness that you can’t construct meaningful tests. Admittedly, these are somewhat strawman requirements, but I’ve seen similar concepts used in my work.

The approach many developers take with bad requirements is to prototype a solution and see how close they get. After a few iterations on a prototype, the developer can usually get pretty close…but by that time, the code is written, so we’ve lost many of the benefits of TDD. Since the code is already written, I’ve often seen developers simply skip writing the unit test.

If we start from testable requirements, TDD becomes much more intuitive, so developers are more willing to adhere to that strategy.

To help developers dive into TDD, I think those doing requirements gathering need to do a better job writing testable requirements to make developer (and tester, for that matter) jobs easier.

The other major benefit of TDD that seems to have been overlooked in this post is that these unit tests can generally (if written using JUnits, for example) be integrated into a regression bucket that can be run at each build. By using TDD, you’re constantly adding tests to your bucket and catching bugs sooner.

Anyway, excellent post. I’ll look forward to reading more!

I’d like to supplement your reasoning with a couple of guidelines for writing and organizing tests:

http://www.bugfree.dk/blog/2009/06/19/my-unit-testing-guidelines/

For some reason it’s a challenge to convince developers to test. The Return on Investment isn’t obvious to many developers.

I think one reason is that people mix the concepts of unit testing and integration testing, partly because a unit testing framework is used for both.

People new to unit testing frameworks often start writing integration tests because they’re the easiest to write. Unfortunately they’re also the most brittle, and tend to fail for no apparent reason — when some dependency isn’t properly configured. After a few such false positives developers grow tired of testing because they find the maintenance cost too high.

Another reason is that unit testing is simply hard. Getting used to think in terms of testability doesn’t come natural to many developers. The same goes for dependency injection and mocking frameworks.

In addition many frameworks used by the application aren’t written with testability in mind. And so extra effort must go into mocking their APIs.

Finally, in my experience, organizing tests so that a team of developers are comfortable with the structure is paramount to success. Basically, a common set of guidelines should be in place from early on and at least one team members must be passionate about testing for it to take off.