Matthias Jauernig has begun a series of articles at http://www.minddriven.de/?p=608 that compares and contrasts TDD and DbC in an effort to help us identify how to use both methods together. If you are interested in this topic, I highly recommend it. It methodically examines some relationships between these two practices.
Here are some of my thoughts on the synergy:
Rythm of my development cycle
I use both TDD and DbC liberally. I use TDD to start the process and drive the design. With TDD we start with Red (failed test). I add contracts during the implementation until we reach Green (test passes) and I add contracts again during refactoring if appropriate.
Postconditions resemble Test Assertions
I examine test assertions as inspiration for identifying missing postconditions. This is a useful advantage of using both TDD and DbC together. Automated tests can be much more versatile than contracts. By this I mean there will be times when a test easily expresses what the final result is, but no reasonable postcondition could be written for the general case.
Contracts can be ON at all times
Contract runtime verification may be configured to be on in various environments. When enabled, contracts perform their verification role in every case a feature is called, not just during the execution of a specific automated test case, but during EVERY execution of a feature, whether it is automated or manual or even usage in production.
So, borrowing Matthias’ language, the test case gives examples of proper usage. But the contracts catch accidental cases of improper usage.
In part 2 of his series, Matthias refers to the “locational gap” in which he writes
“If developers want to show how a component behaves they have to cross the gap and investigate the tests.”
As he says, developers unfamiliar with automated tests may not take full advantage of what they can teach. I have actually been in shops in the past where other developers ignored the automated tests and let them fail. Yes, I know that indicates a serious lack of accountability, training, or something. But it happens. In contrast, contracts are very hard to ignore. When violated, they make your program fail in spectacular ways that make it hard to claim “the software works for me”.
I’m not arguing against holding people accountable for some discipline around builds and testing. I am just saying that contracts help encourage good behavior.
Topics not yet covered
There is more to be discovered about TDD with DbC. And that’s not all! How will the test case generator, Pex alter the balance. My colleague Jason Bock is a big fan of Pex. Martin Angler just wrote an article on this. I am very excited to read it. When I get some free time <laughing> I hope to learn more about Pex and look for effective ways to incorporate it into my practice as well. But not tonight. Time to sleep.