--- title: "The Three Values of a Good Isolation Framework" url: "https://osherove.com/blog/2012/10/14/the-three-values-of-a-good-isolation-framework.md" canonical: "https://osherove.com/blog/2012/10/14/the-three-values-of-a-good-isolation-framework.html" published: "2012-10-14T21:27:44" updated: "2012-10-14T21:27:44" tags: [] author: "Roy Osherove" description: "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…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # The Three Values of a Good Isolation Framework By Roy Osherove October 14, 2012 **Historical article** · Originally published October 14, 2012; technical details may be outdated. I’m working on the 2nd edition of “[The Art of Unit Testing](http://artofunittesting.com/)” 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: [![image](https://osherove.com/img/sq/51559367-Windows-Live-Writer-5a74f2a3c55f_147C4.png)](https://osherove.com/s/files/Windows-Live-Writer-5a74f2a3c55f_147C4.png) 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](http://www.telerik.com/help/justmock/basic-usage-recursive-mocking.html).  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? --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/