Design By Contract and Test-Driven Development [closed]

Question

I'm working on improving our group's development process, and I'm considering how best to implement Design By Contract with Test-Driven Development. It seems the two techniques have a lot of overlap, and I was wondering if anyone had some insight on the following (related) questions:

• Isn't it against the DRY principle to have TDD and DbC unless you're using some kind of code generator to generate the unit tests based on contracts? Otherwise, you have to maintain the contract in two places (the test and the contract itself), or am I missing something?
• To what extent does TDD make DbC redundant? If I write tests well enough, aren't they equivalent to writing a contract? Do I only get added benefit if I enforce the contract at run time as well as through the tests?
• Is it significantly easier/more flexible to only use TDD rather than TDD with DbC?

The main point of these questions is this more general question: If we're already doing TDD properly, will we get a significant benefit for the overhead if we also use DbC?

A couple of details, though I think the question is largely language-agnostic:

• Our team is very small, <10 programmers.
• We mostly use Perl.

Answer 1

Note the differences.

Design driven by contract. Contract Driven Design.

Develop driven by test. Test Driven Development.

They are related in that one precedes the other. They describe software at different levels of abstraction.

Do you discard the design when you go to implementation? Do you consider that a design document is a violation of DRY? Do you maintain the contract and the code separately?

Software is one implementation of the contract. Tests are another. User's manual is a third. Operations guide is a fourth. Database backup/restore procedures are one part of an implementation of the contract.

I can't see any overhead from Design by Contract.

• If you're already doing design, then you change the format from too many words to just the right words to outline the contractual relationship.

• If you're not doing design, then writing a contract will eliminate problems, reducing cost and complexity.

I can't see any loss of flexibility.

1. start with a contract,

2. then

   a. write tests and

   b. write code.

See how the two development activities are essentially intertwined and both come from the contract.