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:

[Test]
public void ReceiptTotalForASaleWithNoItemsShouldBeZero()
{
    var receiptReceiver = mockery.NewMock<IReceiptReceiver>();
    var register = new Register();
    register.NewSaleInitiated();

    Expect.Once.On(receiptReceiver).Method("ReceiveTotalDue").With(0.00);

    register.SaleCompleted();
} 

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.