Choosing a Mock Object Framework

43 Comments

• I'd go with RhinoMocks.
  
  1. Development is very active.
  2. Strongly typed.
  3. Supports Generics.
  4. Free and Open Source
  

• Hi,
  
  Rhino Mocks without any hesitation.
  It is full featured, up to date, and free to use. Any reader of the book can download it and use it without questions. Many newcomers pick it as it matured a lot and match commercial alternatives.
  
  My 2 cents.
  

• I'm casting my vote for RhinoMocks. I just started using it for the last week or so, after having used Nunit.Mocks for well over a year. And man, it blows away NUnit.Mocks. Great framework. Very clean API.
  

• Hi Roy,
  
  I remember feeling the same dwindling motivation for out-of-hours work when my daughter was born. Try basing some of your samples on your son. That should help a bit :)
  
  As for UT frameworks, I have nothing to add. I do want to say that I am looking forward to your book because my enthusiasm for unit testing has actually dwindled a lot of late. It often feels like a lot of effort for little reward, but - more importantly - it often feels like your fighting against the UT framework and / or CLR just to UT your code.
  
  I wish someone could tell me why we need UT frameworks at all. Why can't the CLR provide unit testing capabilities as a service? Then our UTs would be first-class CLR citizens and would have all the access / mocking abilities etc etc that they need and that they simply do not get with *any* of the UT frameworks.
  

• I'd say go with RhinoMocks. It's the best free mock framework out there and it has a pretty good user base from what I understand.
  

• As a happy user of TypeMock, Please note that TypeMock does not require you to input strings for method names you'd like to mock (as long as they are public)
  e.g.
  // mock a static method
  using (RecordExpectations rec = new RecoredExpectation())
  {
  ClassToMock.StaticMethod(1,2);
  rec.Return("dummy").CheckArguments();
  }
  
  and
  // classic mock object
  ClassToMock mocked = RecoredManager.CreateMockObject();
  using (RecordExpectations rec = new RecoredExpectation())
  {
  mocked.Method(1,2);
  rec.Return("dummy").CheckArguments();
  }
  // pass mock into test object
  classUnderTest.CallMethod(mocked);
  
  or mock the instance returned by next new.
  using (RecordExpectations rec = new RecoredExpectation())
  {
  ClassToMock mocked = new ClassToMock();
  mocked.Method(1,2);
  rec.Return("dummy").CheckArguments();
  }
  // no need to pass mock into test object
  // when new ClassToMock is called it will be a mock
  classUnderTest.CallMethod();
  

• Rhino Mock is definitely a must, specially because it's strongly typed, therefore you don't have to check ten times the name of your function when something doesn't work. It’s also open-source, so even if the main (only?) contributor stops working on it, the project might continue with someone else.
  

• Rhino Mocks rules :)
  

• Rhino Mocks. It's good generally but the deciding factors are (a) it doesn't use strings and (b) it's free.
  
  Not using strings means it's much less fragile - you can make better use of IntelliSense and refactoring. This robustness was the killer feature for us. We'd have been prepared to pay for TypeMock, but we eventually ruled it out TypeMock because it's *too* powerful - it looks too easy to shoot yourself in the foot with it. Cost wasn't the deciding factor, but did help to tip the balance.
  

• nMock AND Rhino Mocks.
  
  Start of with hand written mock classes, then cover nMock, then show how Rhino Mocks can be used to remove the method name strings.
  

• Ian:
  I'm already covering hand written Mocks and stubs in the previous chapter. Chapter 5 is all about Mock Object Frameworks, so it has to focus on mock framework benefits.
  I'm not sure covering 2 mock frameworks won't just confuse the reader, but I'm not sure.
  
  In any case, if I am planning on covering 2 frameworks, I'd rather start with the simplest one (NUnit.Mocks) and then move on to either NMock or RhinoMocks, which seems to be the concensus so far..
  

• Why not skip frameworks altogether and use handwritten mocks? Then nothing would be obsolete.
  
  I think the preferred framework depends on what you are going to mock, and your testing strategy. If our tests are small and simple, and test truly one thing, then we don't need complex frameworks.
  
  Personally, I find tests written with the syntax RhinoMock use, is hard to understand. People new to TDD would probably find them hard as well. It is confusing to see the same code lines twice, once for recording, and once for the actual run.
  
  But the real turndown for me, not related to any particular framework, is that mocking frameworks encourage me to write implementation oriented tests, but not behavior oriented tests. Too often, I have ended up with tests which inhibits my code to be refactored.
  
  An example: When I test my presenter to display some value in the view, I couldn't care less where the value comes from, as long as it is the expected one. But using the usual mocking frameworks, I have to pay attention to where they come from. A move method would break my test.
  

• Thomas:
  Interesting points. I do see a need for a more elaborate frmaework for mocking in some cases (though 80-90 % of th etime I find myself doing manual mocks anyway). Some of the reasons may include: The ability to verify multiple parameters more easily, removing the need to imeplement a very large interface, verifying or stubbing out multiple method calls as part of one logical behavior etc..
  The may help with the maintenance aspects of tests, but they can also hinder them if overused to a point.
  
  I also think there should be a place in a book about unit testing that explains and samples Mock Frameworks, if only to let the reader kow what's out there and possible beyond just manual mock, don't you?
  

• Huge fan of RhinoMocks here.
  

• Another RhinoMocks fan here
  

• Definitely a fan of RhinoMocks.
  
  I would avoid using typemocks as an example in the book because it allows you to write your code in a way that isn't quite test-driven just because it allows you to mock *anything*. I think it encourages bad habits.
  
  Stick with something simple here. The most sophisticated I would go would be RhinoMocks. TypeMock is expensive, so you'll have more audience inclusion if you use a free framework.
  

• Yet another RhinoMock fan...
  

• There's nothing saying that you have to standardize on any one mocking framework. They all work together just fine (use one for this text fixture, another for another). I just plunk them into the repository and let the developers use them if they want to or roll their own if they want. The choice of which is better is irrelevant. The choice as to what functionality they provide is most important and can be strongly contextual (to the developer's experience or need). Let them decide. It doesn't hurt a project to include more than one.
  

• I would say Rhino.Mocks as well. I love TypeMock, I think it's an incredible framework...but I think that it's best served for testing legacy code simply because it's so powerful. That much power can let you get lazy and lead to less testable designs. Rhino.Mocks gives you all of the power of a first class mocking framework, while still 'encouraging' you to adhere to more testable designs. A book about unit testing should encourage testable designs from the start, not ways to work around non-testable designs with more powerful tools. The reader will no doubt figure out the more powerful tools on their own once they understand 'why' their design isn't testable. I'm not saying that testing legacy isn't an important topic, it's very important, but it may not be appropriate for a primer.
  
  Also, I would agree that as a reader I would be far preferable to following along with a free/open source framework rather than a commercial one. It is worth noting, however, that TypeMock does have a very nice community edition is which is a completely free download.
  

• I can see the case for Rhino Mocks, but I have become addicted to TypeMock. Combining it with IoC containers has allowed testing of code with no further modifications - allowing the elimination of many dependencies. It is also a lot faster to use that the other mock frameworks that require you to extend or implement anything. I would say use Rhino Mocks and TypeMock. They both have their uses.
  
  TypeMock is a bit more complex than NUnit.Mocks, but for speed of development and capabilities I have to say go with the more complete framework - the learning curve is pretty small.
  

• RhinoMocks, for the following reasons
  1. Solid feature set.
  2. Up to date and kick’n
  3. Free
  4. The syntax is more expressive and feels more “natural” (I know..subjective)
  5. Forces you to inject your mocks (as opposed to TypeMock) which in turn forces you to evolve your class design(usually to a more loosely coupled one ) and supports the notion of unit testing as a design activity
  

• RhinoMocks is pretty much a must. Oren has done such a great job at keeping it current. He's also very responsive to the community.
  

• I'd still like to see coverage of TypeMock even if it isn't OpenSource. I've heard its the Rolls-Royce so it would be nice to have a handy reference when we buy your book!
  

• It really depends on who you see as the audience for your book. Is it those who are fervidly Open Source/Free Software? Or is it those who are commercially-driven, i.e., "just show me how to get the job done most efficienctly." For me, spending $300 to save 2 hours a week, or even 1 hour (which on a yearly basis nets me Golden Arches pay...) is an incredibly good deal. So decide on your audience. If you are selling your book, you might also want to ask which audience is most likely to buy your book.
  

• "I also think there should be a place in a book about unit testing that explains and samples Mock Frameworks, if only to let the reader kow what's out there and possible beyond just manual mock, don't you?"
  
  Very good point, Roy! My mind was clouded by my own experiences. Everyone has their right to make their own choices.
  
  My rather unclear point, or more correctly, my wish, is you to present solid guidelines on how to use mocking frameworks to help the code to evolve and scale. In other words: leaving the tests refactor-friendly.
  

• Scott Hanselman also recorded a podcast on mocking tools.
  

• I think you should go with Rhino Mocks. I'm using it for about half a year now and I didn't regret it for a second. It's free, it's very active, it's fantastic, it still demands a test-driven design as opposed to TypeMock and it's taking over the mocking world.
  

• I am happy to see that most people vote for Rhino Mocks. It is THE framework i would like to read about.
  

• In a word RhinoMocks!
  

• I'm voting for a side-by-side COMPARISON of Rhino.Mocks, TypeMock and NMock2.
  Do everything three times and let the readers choose their own Mocking Framework.
  

• Rhino Mocks, since the refactoring support (if you can call it that) just rocks.
  
  Whatever you do, don't use TypeMock. The 'feature' that allows you to mock ANY type is actually a huge disadvantage IMO, since it allows sloppy API design.
  
  Other mock libraries have the added benefit that they help enforce testable designs.
  

• Rhino Mocks! The reason is that it has a cleaner API overall and it doesn't cause problems while refactoring.
  

• Cast another vote for RhinoMocks. It's a great framework with a natural feel to it. The resulting code is easy to read and the API is clean to code against.
  

• I’ve started using TypeMock not long ago. It rocks. I haven’t looked back since.
  
  Event though it is a commercial product, their community edition includes most of the features required for mocking.
  

• Rhino Mocks... hands down.
  

• Anothe vote for Rhino Mocks!
  

• ... it doesn't mock EVERYTHING... In fact, you can't mock ANYTHING in MSCORLIB which, for some, is a HUGE problem.
  

• The TypeMock Community version is currently free and it is a solid framework.
  
  I would be inclined to go that route. If there are mocking scenarios in the book that require some of the professional features then just identify them as such. The professional/enterprise versions can also be downloaded as demo's as well so I dont see it as a big problem. You can also possibly get some $ support from TypeMocks for featuring their product. Oh. and for Alex... mscorlib is supported with the latest version of TypeMocks
  
  While I think it sucks... there are tons of books out there that include trial versions (dreamweaver and photoshop come to mind) so many developer types are fairly used to seeing this. However if you can bundle the community version on a CD with the book then it will never be outdated realtive to the content of your text. Win-Win for you especially if they chip in with financial support.
  
  

• I use TypeMock and Rhino Mocks.
  
  In our domain classes (Customer/Order etc) implementing interfaces or including virtual methods just to allow mocking using Rhino Mocks results in a design that's complex in ways that don't help, thats when I find TypeMock useful.
  

• I wouuld like to point out that TypeMock.Net has few different versions: Free one which does not include mocking capability for the mscorlib types, and the Enterprise version which does (but costs $299).
  
  Now my question is: Does Rhino Mocks support mocking of all of the types in mscorlib? The reason I am asking is that I beleive that I have read one of the Scot Hanselman's posts that states that the technique that Oren uses in Rhino mocks is that he creates a new type that inherits from the type being mocked, and implements its code there in order to mock the type. Since many of the types in that library are "sealed", then Rhino Mock should not be able to mock them, or am I missing something here?
  

• Our team is using NMock2. The API is quite nice. For simple mocking it is perfect. The disadvantages are:
  - No support for raising events by mock objects.
  - Its a pain to mock library class, because you have to define your own interfaces and implement wrapper classes. I had this problem recently, because I had to test classes using for example the EventLog, PerformanceCounters, the Registry and the ActiveDirectory.
  
  After I read the previous comments, I will try out TypeMock.
  Your book will be of great value if you not only show simple mock cases, but also some examples covering the more difficult cases. Every developer practicing TDD will be confronted with them sooner or later.
  

• Lets start with a simple example of a test using RhinoMocks
  
  Expect.Call(model.GetUser("45")).Return(user);
  view.FirstName = "Roy";
  repository.ReplayAll();
  presenter.Initialize();
  
  Now with NMock2:
  
  Expect.Once.On(model).Method("GetUser").With("45").Will(Return.Value(user));
  Expect.Once.On(view).SetProperty("FirstName").To("Roy");
  presenter.Initialize();
  
  RhinMocks is easier to the developer because you get typed tests, which in turn gives the flexibility to generate the neccesary method/property stubs. What I find annoying is the 'repository.ReplayAll();' that is necessary to signal to the mockframework that the test has been set up and will now be executed.
  
  For NMock2, the string method and property declarations are a pain, I know. The refactorings are harder that way, but that will be caught early when the test fail, so that's really a non issue. However, I still find NMock2 more fluent in the expression of INTENT. Don't forget that code gets READ much more often than it gets WRITTEN (Write Programs for People First, Computers Second - Code Complete).
  
  Just my two eurocents;-)
  

• Damn, just when I was arguing for readability, I manage to post a comment that is one big paragraph, code examples included ;-)