Reflecting reality

Reading over the latest MSDN magazine issue, I’m always encouraged when I see something that I consider important on the cover, Test-Driven Design.  It covers one of the more difficult technical aspects of TDD, which is mock objects.  It took me a couple of years before I really understood the “right” way to use mocks as a design tool, and it wasn’t until I read the Meszaros book that the concept of direct and indirect inputs and outputs laid down simple rules for mock objects.

The really strange thing about this article is that it uses NMock as its mock object library.  NMock?  Nothing against the library, but I can count at least two mocking frameworks that are more popular, Rhino Mocks and Moq.  From folks I talk to in the ALT.NET circles, it’s the vast majority of folks using Rhino Mocks, with a healthy following of Moq.  Folks using NMock are those stuck on older codebases, as NMock is (as far as I can tell) the earliest mocking framework for .NET.  It’s all well and good to show one mocking framework, if that’s the one you’re accustomed to, but to not even mention the most popular mocking framework in .NET?  A little strange.

So what’s the real issue?  Here’s some example code from the article:

public void ReceiptTotalForASaleWithNoItemsShouldBeZero()
    var receiptReceiver = mockery.NewMock<IReceiptReceiver>();
    var register = new Register();



This is frustrating, string-based mocks?  Here’s a fun TDD exercise, rename the ReceiveTotalDue method, and watch how many tests break for the wrong reason.  Tests should fail because of assertion failures, not because I renamed a method.  Additionally, the Arrange-Act-Assert syntax is nowhere to be found.  The AAA syntax made mocking fun, and for me, useful, as the record-replay model led to brittle, difficult to read tests.

Digging deeper, it turns out that the article was written by a ThoughtWorker, and ThoughtWorks sponsors the development of NMock.  I’m glad that mocks got some love in MSDN, but I’d rather the article reflect today’s reality of using mocking frameworks.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in TDD. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • jdn

    Your point is not without merit, but given that the vast majority of people don’t use mocks at all, I think it might be counter-productive to criticize this too much.

    I mean, once people get the ‘mock bug’, they will find the mocking libraries that make their work more productive.

    And let’s not forget that up until recently, e.g. learning Rhino Mocks meant learning record-replay. At least, that is how I learned it originally.

    It is easy for people who on the path of ‘A to Z’ are already at, say, stage ‘G’ to forget that many people haven’t even gotten to ‘A’ yet.

    Introducing Mocks to the wider MSDN audience, to me, is a good thing.

  • Hey Jimmy
    Thanks for the feedback, I had a side bar explaining why i chose to use NMock as a lot of people asked me this question when i got it reviewed. Its not because thoughtworks sponsored the project in the past but because i have some fairly opinionated views, which many may not agree with. Unfortunately this content along with some other content got cut from the final version. For the article i found NMock was the best choice of api, since it has a domain specific embedded language that clearly, precisely, and declaratively describes object communication.
    I know a lot of people have different opinions on this for this reason i also wrote the code examples using rhino mocks.
    On our current project we are using nmock on a fairly large code base.

  • @jdn

    Ah, I definitely agree that introducing mocks to a wider audience is a good thing. But I’d rather skip the whole “record/replay” model altogether, I find it inferior to AAA syntax.


    Thanks for the clarification! I still disagree with NMock’s opinions though :) The expectations model puts the assertions in the wrong place, I believe. Even though you have the “VerifyAll” at TearDown, putting the expectations before the execute/act phase of a unit test is confusing, IMO. I like to see _all_ assertions, explicitly declared, after exercising the SUT.

  • zac

    For what it’s worth, resharper’s rename will also search strings so rename refactorings won’t necessarily break tests using NMock or other string expectation based mocking frameworks.

    That said, NMock does seem a bit outdated.

  • Danilo Mendoza

    I respectfully advise you: why not to write your own article? The community would benefit from it, the same as it benefits from Isiah’s article.

    Thanks for the article. You’re a playa, so naturally you will have some haters.