Moq’s MockBehavior

Moq has been getting some press lately because it’s the newest mock framework on the block. I think it’s certainly interesting and I’ll have more to say on it later, but I wanted to briefly complain about one aspect real quick.

Moq touts that it has a more simplified API when compared to something like Rhino.Mocks. The API has a single entry point which certainly aids discoverability, but I question one of the design decisions. I remember seeing someone say that Rhino had too many types of mocks and that that was confusing. Well, I don’t think it has this many different Mock Behaviors:

  public enum MockBehavior
  {
    Strict, 
    Normal,
    Relaxed,
    Loose,
    Default = Normal,
  }

Why have this many? Does anyone know what they do just by looking at them? At least they’re documented, but the docs are quite a mouthful:

  public enum MockBehavior
  {
    /// 
    /// Causes the mock to always throw 
    /// an exception for invocations that don't have a 
    /// corresponding expectation.
    /// 
    Strict, 
    /// 
    /// Matches the behavior of classes and interfaces 
    /// in equivalent manual mocks: abstract methods 
    /// need to have an expectation (override), as well 
    /// as all interface members. Other members (virtual 
    /// and non-virtual) can be called freely and will end up 
    /// invoking the implementation on the target type if available.
    /// 
    Normal,
    /// 
    /// Will only throw exceptions for abstract methods and 
    /// interface members which need to return a value and 
    /// don't have a corresponding expectation.
    /// 
    Relaxed,
    /// 
    /// Will never throw exceptions, returning default  
    /// values when necessary (null for reference types 
    /// or zero for value types).
    /// 
    Loose,
    /// 
    /// Default mock behavior, which equals .
    /// 
    Default = Normal,
  }

I’m of the opinion that you should only have one type of Mock, and that’s what Rhino calls Dynamic and Moq calls Loose. I described why here. If I wanted to simplify mocking, I’d start here.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://codebetter.com/members/aaronjensen/default.aspx aaronjensen

    Sanoj,

    I can’t say I agree with you. Strict mocking should almost always be avoided unless you have a very specific use for it. It tightly couples your tests to your implementation and makes them fragile.

    Also, I looked at simpledotnet. It appears that it is a “classic” record/verify framework (Yes, I realize it doesn’t have a record or playback method, but neither do moq or rhino now a days). All the other .NET frameworks have moved on to AAA syntax (asserting things were called *after* they were called rather than expecting them *before*). I’d strongly recommend simpledotnet did the same, though to be quite frank, I see no need for another mocking framework. Moq is, for the most part, simple and easy enough to use. And Rhino is as well if you ignore 80% of it’s API.

  • Sanoj

    Mockers should use Strict by default. A really good and simple mocking framework for .NET is

    http://simpledotnet.codeplex.com

  • http://www.clariusconsulting.net/kzu Daniel Cazzulino

    Just wanted to give you a heads-up that thanks to your (and others’) feedback, we’ll be simplifying the API to just Strict and Loose (http://code.google.com/p/moq/issues/detail?id=33).

    Next version will no longer contain the documentation or intellisense for the additional (seldom used, we learned) members (they will be there just to redirect people via [Obsolete] to the appropriate replacement), and will be gone in the following version.

    Thanks for your feedback! We need these sanity checks to keep the API as simple as possible.

  • http://www.flux88.com Ben Scheirman

    sounds like a list of available pairs of Gap Jeans.

  • http://codebetter.com/blogs/aaron.jensen Aaron Jensen

    @Jimmy
    Agree that the “classicist vs. mockist” thing is obnoxious. You should just test things the way they make sense. The biggest laugh I have is when people hand roll mocks with boolean flags they set when something gets called, and then assert that’s true… and then call it state based. Wow.

    That said, there is value to not overmocking as it enables you to test things closer to the real world. There is also value to mocking everything because it allows tests to only test what they’re trying to test… so I understand the argument.

    @Colin
    Yeah, mostly stubs/setupresult like Jimmy said. I use Expect.Call when I expect it, and Expect.Call…Repeat.Never when it must not happen.

  • http://colinjack.blogspot.com Colin Jack

    “And, I think the “don’t use VerifyAll” means “prefer SetupResult.For”, and only do Expect.Call and Verify when you want it to break when it _isn’t_ called.”

    I must admit I don’t use Rhino Mocks much so I didn’t immediately get this but I did Google it and I think I’m on the same page. I’m just thinking that if you setup mocks and don’t verify any of their expectations then you’ve effectively created a stub (which is what SetupResult.For seems to be about).

    This is obviously fine, just when I think of someone saying they’re a mockist then I’m thinking they tend towards interaction testing over state testing. Rethinking this maybe that isn’t a good assumption?

  • http://colinjack.blogspot.com Colin Jack

    @Jimmy
    Fowler makes it clear that classicists DO use doubles:

    “The classical TDD style is to use real objects if possible and a double if it’s awkward to use the real thing. So a classical TDDer would use a real warehouse and a double for the mail service. The kind of double doesn’t really matter that much.

    A mockist TDD practitioner, however, will always use a mock for any object with interesting behavior. In this case for both the warehouse and the mail service.”

    However using a test double is not the same as using mock. I also think that using mockist development does result in different results so I think Fowler is making a perfectly valid point.

  • http://jimmybogard.lostechies.com Jimmy Bogard

    @Colin

    I think the whole “classicist vs. mockist” is a bunch of hooey. Baloney, malarkey even! Are there folks that don’t use test doubles? I would say they’re not doing real unit tests, but integration tests in disguise.

    And, I think the “don’t use VerifyAll” means “prefer SetupResult.For”, and only do Expect.Call and Verify when you want it to break when it _isn’t_ called.

    @Aaron

    That’s what bugged me too the first time I saw it. Less mock methods, but now an enumeration that has…more ways to mock? How is that simpler?

    I don’t really find mock.Object simpler, either. That means I have to have a single Mock instance for everything I Mock.

    Could go on…

  • http://colinjack.blogspot.com Colin Jack

    “Don’t use VerifyAll. What!?!? That’s right, half the time I use Verify(someMock) and the other half I don’t even Verify anything (as I can verify the result of a method called). Your tests should be complete enough that it shouldn’t matter if ObjectA called ObjectB as long as ObjectA gives you the correct result.”

    Was just re-reading this part of the other article, does this not technically mean that you prefer state testing with stubs?

    I guess I just don’t consider it a mock if I don’t verify, but I’m guessing you’d use mocks (even ones that aren’t verified) instead of real components which is why you’re not a classicist.

    Anyway found your points at the end of the other post very relevant and I think if mockers followed your advice then mocking test quality would definitely rise.