> 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.)

> None of the languages I can think of at-the-moment provide
> compile-time verification of array bounds
> in-the-general-case, nor compile-time verification of the
> absence of integer overflow.

> Nonetheless, we seem to have monthly buffer overflow
> patches as a reminder that some languages don't provide
> the run-time bounds checking that Hoare considered
> essential 40 years ago.

This is very interesting. I didn't get it from the article at all, but it seems like what you're saying is that the purpose of DbC is to provide the fastest possible failure path in the event of an error invoking a contract, and to note all the conditions which should cause something to fail.

If this is the case, then we are in violent agreement about what's necessary - as I was saying before, unit tests must verify that the program responds to invalid inputs correctly.

> Firstly, "unit tests" are only present at test-time,
> assertions are present every-time the program is run.

> Secondly, TDD is said to be a design technique not a
> testing technique; unit testing is a testing technique -
> so TDD has "programmer tests".

So I guess from my test-infected perspective, I use TDD to arrive at correct contracts more quickly. Is the fundamental technique of "design by contract" inserting assertions? Is there ever a time when these assertions can cause performance concerns (and are those concerns usually a bad idea to pay attention to, like spurious objections to garbage collectors, et. al.)?

The thing that still eludes me is what technique DbC proposes we use for arriving at which pre/postconditions are critical and which are extraneous. I understand the logic behind the TDD approach to locating these, but in the absence of postulating a test which fails and which an assertion could describe the failure mode of before the code executed, what other testable analysis techniques can be employed?

Also, what do you mean by "programmer tests"?

Thank you for these corrections, they were enlightening.