Search The Blog
Latest Posts
Twitter: @RoyOsherove
About this site

TDD in .NET Online Course

TDD and BDD in Ruby Online Course



This site aims to connect all the dots of my online activities - from tools, books blogs and twitter accounts, to upcoming conferences, engagements and user group talks.

« Build Bullet #1 - Use Version Aware Build Scripts | Main | Polite Code, News Articles, And Pulling Out Early »

The Three Values of a Good Isolation Framework

I’m working on the 2nd edition of “The Art of Unit Testing” and this is one of the topics I plan to cover. A good isolation framework(mocking framework… but that is a horrible name for it. the word mock is overloaded already) should follow three values to not be a hindrance, and actually be helpful to me:

  • Simple to use. For example, a single point of entry in the API, easy to remember API, or Intellisense guidance.
  • Test Robustness. Making sure the test can live as long as possible while the system changes, and it only breaks when something important to it changes. Things like recursive fakes help a lot there.So does being non strict by default.
  • Helpful. If something is wrong, the user should not feel stupid. Helpful error messages go a long way. Being specific and not surprising the user as much as possible.

The result of using a framework that does not adhere to these values? You will get sucked into your tests, and instead of saving time, your tests will cost you time, money and unneeded sweat and tears. And then you will want to delete your tests. One day you actually will. And then you will move to a different job and it was all a waste of energy.

in .NET, here is my current view of which frameworks answer these values:



Also, I’ve marked frameworks that are “unconstrained” (ones that can fake whatever they want) in orange.

And yes. I meant it. Justmock does not support recursive fakes.  Justmock supports chained fake expectations (where you can tell a chain of calls to return a value), but it does not by default return fake objects from a fake object’s methods without explicitly being told to do so. That makes us write more and more lines of code as the production code grows to support code we don’t care about. This leads to over specification and fragile tests.



PrintView Printer Friendly Version

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
Web Analytics