C# Mocking Framework - simple with informative exceptions

Question

So far I've been using NUnit.Mocks to isolate my classes but I am getting annoyed by the lack of feedback it gives me. So I've been looking around for alternatives but getting nowhere.

Rhino Mocks: Can't figure it out. Everything has to be done in a totally different obscure manner making the test code practically unreadable.

Moq: Can't figure out how to mock property getters. There are samples but they don't work when I try them.

From what I've gathered these seem to be among the most popular ones. Before I go and try every single one out there I'd like to ask you folks for suggestions...

What I am looking for:

• Simple design. I don't want to memorize 100 different statements and which one to use depending on whether my method has a return value or not, whether my property has both getters and setters or just one of them, whether it's a full moon or not, etc...
• Elaborate feedback. If my test fails I want to know what method call was missing or too much. I want to know which call had the wrong arguments. Etc...

My background is C# 2.0. I'm still pretty UN-familiar with the concepts in newer .NET versions. So a framework that doesn't require those things would be a bonus.

Thank you.

Edit: I finally figured out why my Moq tests didn't work. It had nothing to do with Moq and I am now evaluating it further. Looks very good so far...

Answer 1

I use Moq and I prefer the implementation rather than the Replay method of some other mocking frameworks - I found it more natural.

What problem are you having with Properties? To mock returning a value from a property it is just

mock.Setup(foo => foo.Name).Returns("bar")

Simple Design

Moq has a fluent interface and the code can be expressive and quite beautiful really. For example:

1. Injecting mocks into object

   mockView = new Mock<IView>();
   mockModel = new Mock<IModel>();
   realPresenter = new Presenter(mockView.Object, mockModel.Object);
   

2. Testing behavior of Presenter reacting to View event

   mockView.Raise(v => v.SomeEvent += null, EventArgs.Empty);
   mockModel.Verify(m => m.DoSomething());
   

Elaborate Feedback

I find the failure feedback very useful and I can usually find the problem very quickly. Say you expect a method with certain parameter value to be called and it fails.

Test 'MyProject.MyTest' failed: Moq.MockException : Expected invocation on the mock at least once, but was never performed: v => >v.DoSomething("Something")> No setups configured.

Performed invocations: View.DoSomething("SomethingElse") at Moq.Mock.ThrowVerifyException(MethodCall expected, IEnumerable1 setups, IEnumerable1 actualCalls, Expression expression, Times times, Int32 callCount) at Moq.Mock.VerifyCalls(Interceptor targetInterceptor, MethodCall expected, Expression expression, Times times) at Moq.Mock.Verify[T](Mock mock, Expression1 expression, Times times, String failMessage) at Moq.Mock1.Verify(Expression`1 expression) MyTest.cs(118,0):

The Moq Quickstart is very well put together and has been the only reference I have needed so far.

Answer 2

FakeItEasy was designed with simplicity (discoverability) and also very importantly feedback as the two main design goals from the ground up.

Another main design goal was readability of the tests.

You say you don't want to remember 100 different statements? Well, good, FakeItEasy uses no more than you can count on the fingers on one of your hands.

For example, configuration and assertion is done through the same statement:

// Creating a fake
var foo = A.Fake<IFoo>();

// Configuration
A.CallTo(() => foo.Bar()).Returns("a value");

// Assertion
A.CallTo(() => foo.Bar()).MustHaveHappened();