For an interesting essay on the relationship between TDD and DbC, see http://www.onestepback.org/index.cgi/Tech/Programming/DbcAndTesting.html

Note also the postscript, where the author admits that he now uses TDD almost exclusively ...

it seems like what you're saying is...
I am not particularly knowledgeable about DbC - there are far better sources of information:
"Design By Contract with JML"
ftp://ftp.cs.iastate.edu/pub/leavens/JML/jmldbc.pdf

to note all the conditions which should cause something to fail
My understanding is that the contract specifies the conditions required for success, not those which should be regarded as failure.

Also, what do you mean by "programmer tests"?
My understanding was that some TDD practitioners have started talking about "programmer tests" rather than "unit tests" to make the distinction that these "programmer tests" are being used to create code - not to test code.

Thank you for these corrections, they were enlightening
And possibly misleading ;-)

For an interesting essay on the relationship between TDD and DbC
Thanks

where the author admits that he now uses TDD almost exclusively...
Perhaps you imply more than the author states ;-)
Maybe the languages he's now using have little support for DbC and good support for TDD?

> Perhaps you imply more than the author states ;-)
> Maybe the languages he's now using have little support for
> DbC and good support for TDD?

That's probably the main reason. As far as I can tell, to do DbC right, it needs to be an integral part of the language you're working in ... otherwise, it's really hard to do preconditions on abstract ("deferred") classes and routines, inheritance of preconditions to preserve Liskov substitutablilty, and automatic documentation of preconditions. This means a) the language has DbC from the start (only Eiffel and Sather, AFAIK), b) the language allows metaobject protocols and hygenic macros (e.g. Smalltalk, Lisp, and similar languages), or c) the programmer introduces a preprocessor (e.g. iContract or JContract for JUnit).

Implementing DbC with macros, metaobject protocols, or preprocessors is probably a lot of work. Aspects may be easier, although I've never liked the idea of contracts in a separate file from the methods they describe; there's too much opportunity for obsolete contracts, and enough context-switching to discourage people from writing contracts unless they have to.

OTOH, unit testing is almost trivial to implement, and covers enough of the same territory. What unit testing lacks is the ability to trap and diagnose problems during acceptance tests and production operation. (Also, implementing "abstract tests" for arbitrary descendants is a real pain, and unit-testing doesn't have the auto-documentation ability of DbC.)

> ... iContract or JContract for JUnit ...

s/JUnit/Java/

Maybe I need a professional proofreader.

You might like to read my paper Contractual Test-Driven Development which I wrote in April 2003 where I explain effective methods to combine TDD and DBC.

http://www.byte-vision.com/CtddArticle.aspx

This was based on a real life project project where I coached and led an XP team for 18 months and we succesfully used both techniques together.

We found DBC and TDD pulled in different directions, but finally found a common ground that was very effective.

It was particularly interesting to actually do the real thing to reach the conclusions after our original theories were blown out of the water when we first tried them.

Suffice to say, there nothing like a good theory being born out of practical experience.

Regards

Dave Chaplin

Contract-Driven Development is fine

test reply