Software development gurus Bob Martin and Jim Coplien go head to head on the virtues (or lack thereof) of Test-Driven Development.

And in this corner, we have Robert “Uncle Bob” Martin, who throws the first punch with the bold: “it has become infeasible for a software developer to consider himself professional if he does not practice test driven development.”

In corner #2, wearing the I [iterate] scrum shirt, we have Jim “TDD will deteriorate your design” Coplien, who hits back with Design By Contract.

In this 20 minute bout, which InfoQ caught on video, Bob Martin explains that “nowadays it is irresponsible for a developer to ship a line of code he has not executed in a unit test” and proposes his 3 Laws of TDD to address this:

1. Write no production code except to pass a failing test.
2. Write only enough of a test to demonstrate a failure.
3. Write only enough production code to pass the test.

The purpose of these laws is to force developers to write their unit tests and production code concurrently (test a little, write a litte, repeat) and thus to guarantee that no production code will ever be shipped without first being tested.

Jim Coplien strikes back with some interesting arguments:

1. If you follow XP-style TDD, you will build an unusable architecture because it forces you to focus on minutiae rather than the overall picture.

2. Testing can never give us 100% coverage. The best we can do is explore some subset of the nearly infinite state space within our public interfaces, and we have to be “really lucky to find bugs like that.” Design by Contract, on the other hand, gives you broader coverage because you’re covering the entire range of the application. AND, it does so while still providing the benefits of TDD: forcing you to think about the code, and focusing you on its external view.

3. In a typical TDD project, you have roughly the same amount of test code as you do production code. Since we all know the amount of bugs in our code is directly proportional to the amount of code, TDD is actually doubling the # of bugs in our applications. Not to mention cutting our velocity in half as we have twice as much code to write.

What do you think?
Watch the video and post your thoughts on Bob’s thesis and Jim’s anti-TDD arguments.

—
» See also: The Various Meanings of TDD for some additional insight into this argument