Software Quality

February 2, 2010

More on the synergy between Test-Driven Design and Design by Contract

Filed under: Uncategorized — David Allen @ 10:51 pm

Matthias Jauernig has begun a series of articles at 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

and vice-versa

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.


  1. Hi David,

    Nice blog and nice thoughts on DbC/TDD and their synergy. You are addressing some interesting aspects which complement and coincide with my thoughts.

    You are making a good point on developers which ignore automated tests. This is a serious problem which I see as well and since this is a lack of accountability, that’s life! It happens in more projects than anybody prefers and it’s an underestimated problem.

    Pex can complement a synergetic TDD/DbC process very well. I see it as important part to take best advantage in a technology-specific way (.NET, Code Contracts, Pex). Last year I had a nice little discussion on that with Peli, a Pex developer: . I will further investigate this and I hope to clear my mind even further.


    Comment by Matthias — February 6, 2010 @ 9:32 am

  2. I look forward to seeing your thoughts on how to integrate Pex within the development process.

    Comment by David Allen — February 6, 2010 @ 2:09 pm

  3. […] be difficult (especially if they don’t see the benefits of TDD). That’s a question of accountability and project lead. There have to be project guidelines which include testing standards and there […]

    Pingback by Comparison: DbC and TDD – Part 4 | Mind-driven development — February 14, 2010 @ 5:23 am

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: