--- title: "Isolation frameworks – lessons from the wild" url: "https://osherove.com/blog/2008/12/3/isolation-frameworks-lessons-from-the-wild.md" canonical: "https://osherove.com/blog/2008/12/3/isolation-frameworks-lessons-from-the-wild.html" published: "2008-12-03T13:20:04" updated: "2008-12-03T13:20:04" tags: [".NET", "Agile", "Typemock", "Unit Testing"] author: "Roy Osherove" description: "I’m in the process of teaching another TDD master class in Oslo this week, and in the past two days we went over the major Isolation frameworks in .NET (I refuse to say Mocking frameworks anymore. the “Mock” work is too…" 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/" --- # Isolation frameworks – lessons from the wild By Roy Osherove December 3, 2008 In [.NET](https://osherove.com/blog/category/net), [Agile](https://osherove.com/blog/category/agile), [Typemock](https://osherove.com/blog/category/typemock), [Unit Testing](https://osherove.com/blog/category/unit-testing) **Historical article** · Originally published December 3, 2008; technical details may be outdated. I’m in the process of teaching another [TDD master class in Oslo](http://www.programutvikling.no/kurskalenderoversikt.aspx?id=218164) this week, and in the past two days we went over the major Isolation frameworks in .NET (I refuse to say Mocking frameworks anymore. the “Mock” work is too overloaded as it is). We covered NMock, Rhino Mocks, Moq and Typemock , and alos as a start we used hand written mocks and stubs, and NUnit.Mocks for entry level learning. Several things can be gleaned from how students reacted to using these frameworks (in random order of thought) - The verification error messages that all three big frameworks (rhino, typemock and mock) throw could be much clearer (expected X but only got Y) - The AAA (Arrange act assert) model for isolaation framework, whilke much shorter, is still not as easy to grasp as you might think for newcomers. In fact, I’m not sure people found it easier than record-replay. - One of the hardest points was remebering the APIs in rhino and Moq, becuase there is more than one entry point to using the API (Constraints alone in rhino have 4 different “root” classes) - The word “Expect” confuses because it makes you think about “expectations” as in interaction testing, when in fact it can be used for stubbing out things. - Once people realized that “Strict” mocks are causing lots of problems, it was one of the first questions they had about any new framework they learned. NMock2 doesn’t have a way to turn off Strict mocks. weird. - Verification Exceptions can be too easily “swallowed” by inner code so the test seems to pass (false positive). i think Isolator is the only one that will re throw swallowed exceptions). - in AAA, People kept doing Expectations or Stubs method return values when what they meant was they want to veify the method was called - Given an interface IFoo with a boolean property,if people want to make the property return a false value they instinctively write “myFake.Foo=false”. All frameworks should support default “property like behavior” to make this possible. Rhino mocks has this ability. - 2 VB.NET students in the class kept hitting walls with everything that had lambdas in it,(Vb.NET has partial support for anonymous delegates) which means right now VB.NET has to use record-replay. - The fact that Moq needs lambda expression trees and not regular lambdas prevents resharper from generating code signatures using smart intellisense. Moq is not resharper-friendly.. - the Moq syntax for constraints is just too complicated (It.IsAny is OK, but It.Is(s=>s.contains”a”) is just too much code noise and complexity - The rhino AAA way of constraints is also hard to remember, but a bit more friendly (but not by much) : Arg.Matches(Text.Contains(“A”) - Mixing inheritance and frameworks fake objects in the same test is very confusing for beginners.Either use an isolation framework or override virtual methods, but not both. - TestDriven.NET wins hands down against resharper unit test runner - People love RowTest (which seems to have been gone with the new version nunit 2.5 and replaced with \[TestCase(values…)\] ) - the book “Test Driven Development with MS.NET” is hideously outdated by now (given out to students) - People want the ability to define a call-by-call behavior of a stub return value. Feels very much like over-specification - With hand written stubs newcomers will easily make the mistake of adding real functionality into the hand written class instead of into the production code. - Test names **really help** to find misunderstood requirements - 3 frameworks in 1 day could prove to be too much information. 2 could be just enough. - When doing TDD people will actually **forget** that they can debug the test to see why it’s not behaving like it should - People really likes the fluent API design of NMock2, but disliked its strictness - If you use moth Moq and rhino in the same test class, you will see all the extension methods mixed up when you open intellisense on any object. \*shiver\* - Isolator was the only one where people didn’t ask me a single question about what API to use. they did put calls in the wrong place in the test though (AAA is hard to get used to) - AssertWasNotCalled feels like over-specification. - lambdas were easier to get used to than I expected. ## Lessons on this topic - [Isolation (Mocking) Frameworks](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/isolation-mocking-frameworks/) · The Art of Unit Testing and TDD in Java - [Isolation Frameworks](https://courses.osherove.com/courses/tdd-in-net-in-hebrew/isolation-frameworks/) · TDD in .NET in Hebrew - [Isolation Frameworks](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-master-class-in-net/isolation-frameworks/) · The Art of Unit Testing & TDD Master Class in .NET - [Using Bogus](https://courses.osherove.com/courses/tdd-and-bdd-in-ruby/using-bogus/) · TDD and BDD in Ruby ## More in .NET [All posts in .NET](https://osherove.com/blog/category/net) - Feb 25, 2009 ### [Adding Method-Missing support to VB.NET using CTru and Typemock Open-AOP](https://osherove.com/blog/2009/2/25/adding-method-missing-support-to-vbnet-using-ctru-and-typemo.html) - Dec 31, 2008 ### [The morning brew](https://osherove.com/blog/2008/12/31/the-morning-brew.html) - Nov 26, 2008 ### [Isolation Syntax for VB.NET - Your comments please](https://osherove.com/blog/2008/11/26/isolation-syntax-for-vbnet-your-comments-please.html) - Nov 24, 2008 ### [Announcing Isolator for Sharepoint with a free full license for bloggers](https://osherove.com/blog/2008/11/24/announcing-isolator-for-sharepoint-with-a-free-full-license.html) --- ## 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/