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.
thoughts?