C# – How to set the Expect call to check that a method is not called in Rhino Mocks

crhino-mocksunit testing

Using Rhino Mocks, how do I ensure that a method is not called while setting up the Expectations on the mock object.

In my example, I am testing the Commit method and I need to ensure that the Rollback method is not called while doing the commit. (this is because i have logic in the commit method that will automatically rollback if commit fails)

Here's how the code looks like..

[Test]
public void TestCommit_DoesNotRollback() 
{
    //Arrange
    var mockStore = MockRepository.GenerateMock<IStore>();
    mockStore.Expect(x => x.Commit());
    //here i want to set an expectation that x.Rollback() should not be called.

    //Act
    subject.Commit();

    //Assert
    mockStore.VerifyAllExpectation();
}

Of course, I can do this at Assert phase like this:

mockStore.AssertWasNotCalled(x => x.Rollback());

But i would like to set this as an Expectation in the first place.

Best Answer

Another option would be:

mockStore.Expect(x => x.Rollback()).Repeat.Never();

Related Solutions

C# – How to use reflection to call a generic method

You need to use reflection to get the method to start with, then "construct" it by supplying type arguments with MakeGenericMethod:

MethodInfo method = typeof(Sample).GetMethod(nameof(Sample.GenericMethod));
MethodInfo generic = method.MakeGenericMethod(myType);
generic.Invoke(this, null);

For a static method, pass null as the first argument to Invoke. That's nothing to do with generic methods - it's just normal reflection.

As noted, a lot of this is simpler as of C# 4 using dynamic - if you can use type inference, of course. It doesn't help in cases where type inference isn't available, such as the exact example in the question.

What’s the difference between faking, mocking, and stubbing

You can get some information :

From Martin Fowler about Mock and Stub

Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production

Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.

Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

From xunitpattern:

Fake: We acquire or build a very lightweight implementation of the same functionality as provided by a component that the SUT depends on and instruct the SUT to use it instead of the real.

Stub : This implementation is configured to respond to calls from the SUT with the values (or exceptions) that will exercise the Untested Code (see Production Bugs on page X) within the SUT. A key indication for using a Test Stub is having Untested Code caused by the inability to control the indirect inputs of the SUT

Mock Object that implements the same interface as an object on which the SUT (System Under Test) depends. We can use a Mock Object as an observation point when we need to do Behavior Verification to avoid having an Untested Requirement (see Production Bugs on page X) caused by an inability to observe side-effects of invoking methods on the SUT.

Personally

I try to simplify by using : Mock and Stub. I use Mock when it's an object that returns a value that is set to the tested class. I use Stub to mimic an Interface or Abstract class to be tested. In fact, it doesn't really matter what you call it, they are all classes that aren't used in production, and are used as utility classes for testing.