Moqs versus Stubs (2013 edition)
February 25, 2013
This is an age old debate which I’ll chirp in with my opinion. According to Gojko Adzic there’s two types of TDD people in the world: classic stubbers and the new(ish)-school Moqers (or Mockito in the Java world). MOQ is an amazing tool, but consider the following test code:
_mockRepository = new Mock<IRepository>(); _mockRepository.Setup(x => x.GetPageById(It.IsAny<int>())).Returns<int>(x => _pageList.FirstOrDefault(p => p.Id == x)); _mockRepository.Setup(x => x.FindPagesContainingTag(It.IsAny<string>())).Returns<string>(x => _pageList.Where(p => p.Tags.ToLower().Contains(x.ToLower())));
Eeek. Is that easy to read? Does FindPagesContainingTag return a string? No, an IEnumerable of Page objects. Compare this to a stub implementation (the classical way of mocking) of the IRepository:
public class RepositoryStub : IRepository { public IEnumerable<Page>FindPagesContainingTag(string tag) { return _pageList.Where(p => p.Tags.ToLower().Contains(tag.Tolower())); } }
The other problem I have with the Moq example is you essentially have the stub class’s source in your [Setup] method most of the time. The advice Bob Martin gives for tests is they’re meant to be very easy to read for the next author, there should be no confusion at all. It’s fairly clear Moq doesn’t promote this, or at least not the messy way I write the mocks. So I’m probably in the classical camp, but is there no half-way house for the two in .NET?
I'm Chris Small, a software engineer working in London. This is my tech blog. Find out more about me via Github, Stackoverflow, Resume