Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time


Spextensions is a set of extensions and utilities for RhinoMocks and NUnit.

The code is licensed under the MIT license, as described in the LICENSE file.


Spextensions.RhinoMocks includes several extensions to the RhinoMocks API to simplify common usage patterns of RhinoMocks. Spextensions.RhinoMocks has no ties to NUnit. You can use it with what ever testing framework you are currently using.


The easiest way to add Spextensions.RhinoMocks to your application is to use NuGet. You can add the package by searching for "Spextensions.RhinoMocks" in the NuGet GUI or by using the package manager console:

PM> Install-Package Spextensions.RhinoMocks


Return sequences

You can set up a mocked/stubbed method to return new values from a given sequence for each time it is called:

var sequence = new Sequence<int>(1, 2, 3);

_stub.Stub(x => x.Function()).ReturnSequence(sequence);

Assert.AreEqual(1, _stub.Function());
Assert.AreEqual(2, _stub.Function());
Assert.AreEqual(3, _stub.Function());


You can perform arbitrary boolean assertions when expectations are matched:

_mock.Expect(x => x.Method())
    .AssertThat(() => condition);

The test will fail if the condition lambda returns false when the mocked/stubbed method is called.

Lazy/overridable return values

You can set up a mocked/stubbed method to return a given value, which can later be changed so that is actually returns another value. This is very useful when most of the test require a certain return value, but one or two tests need another return value. Now you can set up the mock/stub in the SetUp of the test fixture and then just change the return value in the tests that do not want the default behaviour.

public class LazyReturnValueSpecs
    private ISomeInterface _stub;
    private LazyReturnValue<int> _returnValue;

    public void SetUp()
        _stub = MockRepository.GenerateStub<ISomeInterface>();

        _returnValue = LazyReturnValue.Create(1);
        _stub.Stub(x => x.Function()).LazyReturnValue(_returnValue);


    public void Lazily_returning_constant_value_returns_the_constant_value()
        var actualReturnValue = _stub.Function();

        Assert.AreEqual(1, actualReturnValue);

    public void Changing_lazily_returned_value_returns_the_new_value()
        _returnValue.Value = 2;

        var actualReturnValue = _stub.Function();

        Assert.AreEqual(2, actualReturnValue);

Testing order of method calls

Using StrictMocks is simply a pain. If you want to test that methods are called in the correct order, but without having to deal with StrictMocks you can use Signals.

_mock1 = MockRepository.GenerateMock<ISomeInterface>();
_mock2 = MockRepository.GenerateMock<ISomeOtherInterface>();
_signal1 = new Signal("signal description 1");

_mock1.Expect(x => x.Method())

_mock2.Expect(x => x.OtherMethod())

// If the calls are not made in the expected order the signal will not be signaled
// when OtherMethod is called, and the test will fail

Multiple signals can be used simultaneously if you want to check the order of multiple method calls.

Signals are inspired by jMocks States.

Capturing arguments

You can capture the actual values from a call to a mocked/stubbed method:

// Capture argument by type:
int argumentValue = -1;

_mock1.Stub(x => x.FunctionWithOneParameter(1))
    .CaptureFirstMatchingArgument(new ArgumentConstraint<int>(), x => argumentValue = x)


Assert.AreEqual(1, argumentValue);

// Capture argument by type and match index:
string argumentValue = null;

_mock1.Stub(x => x.FunctionWithTwoParametersOfSameType(null, null))
    .CaptureFirstMatchingArgument(new ArgumentConstraint<string>(matchIndex: 1), x => argumentValue = x)

_mock1.FunctionWithTwoParametersOfSameType("string 1", "string 2");

Assert.AreEqual("string 2", argumentValue);

You can extract a parameter by type or by type and index.


It can be frustrating when your stubs/mocks do not get called the way you expect them to. If a mocked method is not called with the correct parameters, you can use debuggins extensions to find out with which parameters the method is actually called.

_mock1.Expect(x => x.FunctionWithThreeParameters(0, false, null))

_mock1.FunctionWithThreeParameters(1, true, "string");
_mock1.FunctionWithThreeParameters(2, false, "other string");

/* Console output:
Stubbed/expected method 'FunctionWithThreeParameters' was called with the following parameters: 1, True, string
Stubbed/expected method 'FunctionWithThreeParameters' was called with the following parameters: 2, False, other string

As the method name implies attaching the debugging output to the mocked method actually adds an IgnoreArguments constraint, so make sure to remove the debugger call when you have found the problem, to avoid leaving a false positive test behind.


Spextensions.NUnit primarily includes fluid, RSpec style, assertion syntax and semantic aliases for attributes:

public class ListSpecs
    private void Clearing_a_list_removes_all_items()
       var list = new List<int> { 1, 2, 3 };


Extensions for RhinoMocks and NUnit







No releases published


No packages published