thanks again for your feedback - appreciate that kind of conversation!
From my viewpoint DBC and Tests aren't competing techniques, rather than tools that could complement one another.
I'll give a brief summary of some issues (most of them are greatly influenced by the book 'Design by Contract by Example'), where it's valuable to think about how DBC could support for a better design. I will elaborate on that thoughts in a separate blog entry under my blog site
as soon time allows some more writing.
1. Rely on a proper context
In my experience, most developers tend to insert guard clauses in their code despite having unit tests. They don't seem to trust about the context in which the method get's called (this maybe comes because of a mental and local 'distance' between the code and the test). Having contracts aside the code you can rely on seems to increase trustability in the running context. This may be because of ...
2. Supporting defensive programming
DBC protects / defend methods from bad arguments in the real hard world, testing potentially a wider range of input than a test ever can do.
3. Clearer, reliable Documentation
Contratcs form part of the public (client-) view of a class (personally i'm lazy - i want to recognize the core behaviour of a building block by looking at its interface / signature, not studying an amount of code be it the building block itself or a test).
Assertions are checked at runtime, thereby testing that the stated contracts are consistent with what the routines actually do.
4. Hepls to test integration
Having contracts that can be turned on and off makes it very easy to test and retest parts of a program. It allows you for instance to continue to test class A while you are working on class B, in case there are any interactions you did not foresee (and anything that helps testing will lead to code with fewer bugs).
5. Encourage to think about the conceptional model of a building block
Thinking about such matters as pre-, postconditions and invariants help to make the concept of a class more explicit. That leads to ...
6. Clearer Designs
Obligations and benefits are shared between client and supplier and are clearly stated.
The limitations on the use of a method are clearly expressed and the consequences of calling it illegally are clear, so programmers are encouraged not to build routines that are too general, but to design classes with small single-purpose routines (while TDD guides more towards loosely coupled building blocks, DBC guides more towards smaller building blocks with a clear resoponsibility).
7. Easier Debugging
DBC can take part in 'real life', that means under real runtime conditions, maybe during development and user acceptance test (they take effect under real circumstances while 'real' clients and real collaborators (maybe also contracted) interoperate with each other. So contracts also guarding the collaboration of muliple building blocks forcing to fulfill a collective adduced goal due to a specification).
Additionally, having clear sound messages that state the cause of a contract violation helps locating where the fault lies semantically.
8. Support for reuse
For library users (where tests may not be accessible), contratcs clearly explain what library classes do and what constraints there are on using them. They provide feedback to someone learning to use other peoples classes.
(sometimes you only know the interface to operate with - the implementing class is unknown. Having contracts on that interface gives you a clear, sound concept of the limitations and relevant effects in programming against that interface in a proper way)
9. Encourage to comply to the open close principle
While tests usually test a single unit, DBC handles inheritance in a broader way, supporting also inheritance of contracts to subclasses and therefore forcing to adhere to the claimed behaviour, stated in contracts of a superclass or interface.
As mentioned above - some of the points briefly. Hoping that i can extend that opinions in a separate blog entry the very next time. As i said - i appreciate that kind of conversation :o)