TDD/BDD and Design by Contract: I don’t really see any conflict between the two

I found an interesting link today from Mario Gleichmann called Test Driven Development and Design By Contract – friend or foe?.  I’ve always been lukewarm toward Design by Contract (DbC).  Occasionally I’ll run into claims from DbC enthusiasts that using DbC completely eliminates the need or desire for Test Driven Development and I’ll start rolling my eyes.  That attitude stayed perfectly intact until I spent some time with Greg Young at DevTeach talking about spec#


After learning a bit about spec# I can see plenty of value for DbC, but certainly not as a full replacement or even an alternative to TDD/BDD.  One way or another it’s all about specifying the desired behavior and using some sort of automation to check that the specification is being satisfied.  What I envision is using DbC to efficiently knock down a lot of the boring problems like erroneously passing nulls around at compile time.  I would still use TDD/BDD to get to the interesting part — the actual behavior of classes and methods.  Greg is claiming that having spec# would replace 2/3 of his unit tests with more declarative DbC style specifications inside the code with arguably a faster feedback loop than running NUnit tests.  All I can say is “cool.”  Cutting down feedback cycle time is always advantageous.  Eliminating tedious imperative code with declarative specifications is definitely good.


I’m not a fan of copious amounts of defensive programming being anywhere but externally facing API’s.  I don’t write a lot of unit tests checking for bad data coming into or out of methods because I don’t see that activity as having a positive reward to effort ratio and I can’t abide clutter in the code.  I haven’t particularly recognized any real pain from not writing these unit tests, but if I did feel that pain, I’d rather just use DbC specifications in the code and get going with the more interesting work.


 

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Test Driven Development. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Greg

    Damn jeremy now I have to write a few pages on this :)

  • http://colinjack.blogspot.com/ Colin Jack

    @John
    No we do that too, as you say just for pre-conditions but as Jeremy says Spec# would remove the need for all those tests.

  • http://jaychapman.blogspot.com John Chapman

    Am I the only developer out there who uses TDD to verify that my contracts are being checked? Maybe I just take it to the extreme? Note that I typically just use the pre-condition contract portion, not the post-condition checks. I rely entirely on my tests for the results.