Posts Tagged With Rhino.Mocks - Musing, Rants & Jumbled Thoughts

Header Photo Credit: Lorenzo Cafaro (Creative Commons Zero License)

I've been a big fan of Rhino.Mocks for many years, but the original Rhino.Mocks maintainer (Oren Eini aka Ayende) stated in 2013 that he is no longer maintaining the project and has handed the project over to a new maintainer (Mike Meisinger), but Mike has not been actively maintaining the project. It's effectively dead and very unlikely to support future versions of .NET, including .NET core.

A while back I wrote a Quick Guide to Using Rhino.Mocks and in last week's post, I gave an overview of Moq for Rhino.Mocks Users. While Moq seems to be the current front runner as a Rhino.Mocks replacement, there's another player in town with NSubstitute. So in the same vane as my Moq post, I'm providing a guide to help people make the transition (or at least help with a review) from Rhino.Mocks to NSubstitue.

The format of this post will follow that of the others to help with cross-referencing between them.

Overall, I'm not a big fan of NSubstitute's syntax, as it looks too similar to just calls to the methods themselves, which:

  • makes it harder to understand, as the reader must know which calls are setting up stubs and which are real calls.
  • makes it much more likely you'll accidentally do the wrong thing and call a real method.

Now, if you're only mocking interfaces, then this wouldn't be an issue -- but rarely do I find a codebase that allows everything to be an interface.

Generating Different Mock Types

By default, NSubstitue's .For<T> method generates something close to a Dynamic mock -- that is, if you don't explicitly provide a return value, it will return the default value for the data type of the return value if it's a value type (0 for numbers, false for bools, empty string for string), but for object types, it's a bit more complicated. From their documentation:

...any properties or methods that return an interface, delegate, or purely virtual class* will automatically return substitutes themselves.

A pure virtual class is defined as one with all its public methods and properties defined as virtual or abstract and with a default, parameterless constructor defined as public or protected.

So it won't return null in those cases. Instead, it creates a new mock of the return type. Otherwise, it will return null.

Be careful, thought -- if you are using a real class (not an interface), it will call the underlying methods if they aren't virtual.

That said, there is the concept of a partial mock using .ForPartsOf<T> -- that is, a mock that can use the underlying object's implementation. However, to prevent calling the real methods for the methods you do want to mock, you must use the syntax described in the Advanced Argument Constraints section below.

Rhino.Mocks NSubstitute
Dynamic-ish Mock IFoo mock = MockRepository.GenerateMock<IFoo>(); IFoo substitute = Substitute.For<IFoo>();
Partial Mock IFoo mock = MockRepository.GeneratePartialMock<IFoo>(); IFoo substitute = Substitue.ForPartsOf<IFoo>();

There isn't an option to create a Strict mock in NSubstitute, and it looks like there won't ever be one.

Passing Constructor Arguments

If you need to pass arguments to the constructor of the class you're trying to mock, there are overloads to allow you to do that.

Rhino.Mocks NSubstitute
IFoo mock = MockRepository.GenerateMock<SomeClass>(param1, param2); Substitue.ForPartsOf<SomeClass>()(param1, param2);

Stubs vs Mocks (or not)

The syntax for NSubstitute is a little different than the others. In most cases, there's not an explicit method you call to create the mock/stub -- rather, you basically call the method you want to create a substitue for. Also, there's no distinction between a mock and a stub -- they're all just substitutions. But since they don't create _expectations_, I would classify them as stubs.

You use the .Returns() method to setup the stub. Note that you can provide multiple values to .Returns() which will set up a chain of calls, like this: .Returns(valueForFirstCall, valueForSecondCall, valueForThirdCall). This works for methods and properties.

For Methods:

Rhino.Mocks NSubstitute
Stub mock.Stub(x => x.SomeMethod()).Return(true); substitute.SomeMethod().Returns(true);
Mock mock.Expect(x => x.SomeMethod()).Return(true); (not supported)

For Properties:

Rhino.Mocks NSubstitute
Stub mock.Stub(x => x.SomeProperty).Return(true); substitute.SomeProperty.Returns(true);
or
substitute.SomeProperty = true;
Mock mock.Expect(x => x.SomeProperty).Return(true); (not supported)

Unlike Rhino.Mocks, however, if some other code sets the property value to something else, NSubstitute's stub will return the new value, not the value you stipulated in your stub. In other words, NSubstitue's properties will act like regular properties, and your stub just sets an initial value.

Verifying expectations

Since you're not creating expectations with NSubstitute, there are no mass validation options. Instead, you need to check each stub (which, being more explicit, is probably the better route anyway).

For Methods:

Rhino.Mocks NSubstitute
Called mock.AssertWasCalled(x => x.SomeMethod()); substitute.Received().SomeMethod();
Called a specific number of times mock.AssertWasCalled(x => x.SomeMethod(), options => options.Repeat.Times(2) ); substitute.Received(2).SomeMethod();
Not called mock.AssertWasNotCalled(x => x.SomeMethod()); substitute.DidNotReceive().SomeMethod();
or
substitute.DidNotReceiveWithAnyArgs().SomeMethod();

For Properties:

Rhino.Mocks NSubstitute
Get mock.AssertWasCalled(x => x.SomeProperty); var temp = substitue.Received().SomeProperty;
Set mock.AssertWasCalled(x => x.SomeProperty = true); substitue.Received().SomeProperty = true;
Not called mock.AssertWasNotCalled(x => x.SomeProperty = true); substitue.DidNotReceive().SomeProperty = true;
or
substitue.DidNotReceiveWithAnyArgs().SomeProperty = true;

Note that for the getter, you must set a variable to the return value to prevent a compiler error.

The WithAnyArgs versions will ignore whatever parameters (for methods) or set values (for properties) you use in your check and will verify against any inputs.

Advanced Argument Constraints

Both frameworks provide ways to put advanced constraints on the arguments that trigger a mock. Below are examples -- you'll need to consult the framework documentation for the full list of available constraints.

Rhino.Mocks

 mock.Stub(dao => dao.GetRecordFromDatabase(
                         Arg<int>.Is.GreaterThanOrEqual(0),
                         Arg<decimal>.Is.NotEqual(2.0),
                         Arg<List<string>>.List.ContainsAll(new List<string> { "foo", "bar" }),
                         Arg<object>.Is.NotNull,
                         Arg<object>.Is.Anything))
                 .Return(recordFromDatabase);

NSubstitute

  substitute.GetRecordFromDatabase(
                         Arg.Is<int>(i => i >= 0),
                         Arg.Is<decimal>(d => d != 2.0m),
                         Arg.Do<int>(x => capturedValue = x ),
                         Arg.Any<object>()))
         .Returns(recordFromDatabase);

Or, to ignore the arguments altogether, use .ReturnsForAnyArgs(). This is similar to Rhino.Mocks' .IgnoreArguments() method.

Providing a Method Implementation / Using the Input Params

For Rhino.Mocks, in order to provide an alternate implementation, you use the .Do() method to provide a delegate. In NSubstitue, you provide a delegate to the .Returns() call.

Rhino.Mocks

  mock.Stub(dao => dao.GetRecordFromDatabase(0))
                .IgnoreArguments()
                .Repeat.Any()
                .Do((Func<int, ImportantData>)(input => new ImportantData
                {
                    Name = "Orignal Name",
                    RecordId = input
                }));

NSubstitute

           
            substitute.GetRecordFromDatabase(0)
                      .ReturnsForAnyArgs(input => new ImportantData
                       {
                           Name = "Orignal Name",
                           RecordId = input.ArgAt<int>(0)
                       });

Throwing an Exception Instead

If the return type of the method is not void, you just provide a delegate to .Returns() that throws an exception. However, if the return type is void, then you use a .When().Do() syntax instead:

Rhino.Mocks NSubstitute
mock.Stub(x => x.SomeMethod()).Throw(new Exception("POW!")); substitute.SomeMethod().Returns(x => { throw new Exception("POW!"); });
or
substitute.When(x => x.VoidMethod()).Do(x => { throw new Exception("POW!"); });

Testing Non-Public Members

With Rhino.Mocks, you can’t mock private or internal members, but you can mock internal members if you add an InternalsVisibleTo attribute for the Castle dynamic proxy assembly. NSubstitute also uses the same proxy, so you'll still need to add the attribute. See the Moq Quickstart Guide for details on how to do this.



I've been a big fan of Rhino.Mocks for many years, but the original Rhino.Mocks maintainer (Oren Eini aka Ayende) stated in 2013 that he is no longer maintaining the project and has handed the project over to a new maintainer (Mike Meisinger), but Mike has not been actively maintaining the project. It's effectively dead and very unlikely to support future versions of .NET, including .NET core.

Moq (pronounced "Mock") has become the de facto replacement.

This post hopes to serve as a guide for people making the transition from Rhino.Mocks to Moq.

One big difference between Rhino.Mocks and Moq is what gets returned when you generate the mock and how you operate against it. With Rhino.Mocks, the MockRepository returns to you an instance of the type you're mocking and you apply the mock operators (.Stub(), .Expect(), .VerifyAllExpectations(), etc) directly to that mocked object. Moq, on the other hand, creates a wrapper object that contains a reference to the mocked type.

So in this example, I'm creating an mock of IFoo. For Rhino.Mocks, I get back an IFoo object, but Moq returns a Mock<IFoo> and to get the IFoo object, you access it with the .Object property.

Rhino.Mocks Moq
IFoo mock = MockRepository.GenerateMock<IFoo>(); Mock<IFoo> mockWrapper = new Moq.Mock<IFoo>();
IFoo mockedObject = mockWrapper.Object;

When using Moq, if you have a reference to the mocked object, you can get back to the wrapper object with this helper method: Mock<IFoo> mockWrapper = Mock.Get(mockedObject);

Generating Different Mock Types

For those of you that read my Using Rhino.Mocks Quick Guide, you may recall there are three types of mocks that can be generated by Rhino.Mocks:

Strict Mock
A strict mock requires you to provide alternate implementations for each method/property that is used on the mock. If any methods/properties are used which you have not provided implementations for, an exception will be thrown.
Dynamic Mock
With a dynamic mock, any methods/properties which are called by your tests for which you have not provided an implementation will return the default value for the data type of the return value.  In other words, you'll get back a 0 for number types, false for Booleans and a null for any object types.
Partial Mock
A partial mock will use the underlying object's implementation if you don't provide an alternate implementation.  So if you're only wanting to replace some of the functionality (or properties), and keep the rest, you'll want to use this.  For example, if you only want to override the method IsDatabaseActive(), and leave the rest of the class as-is, you'll want to use a partial mock and only provide an alternate implementation for IsDatabaseActive().

Note that Moq uses the term "Loose Mock" for the Dynamic mock concept. Both frameworks default to Dynamic\Loose mocks.

Here's how you generate the same concepts in Moq:

Mock Type Rhino.Mocks Moq
Strict Mock IFoo mock = MockRepository.GenerateStrictMock<IFoo>(); Mock<IFoo> mockWrapper = new Moq.Mock<IFoo>(MockBehavior.Strict);
Dynamic\Loose Mock IFoo mock = MockRepository.GenerateMock<IFoo>(); Mock<IFoo> mockWrapper = new Moq.Mock<IFoo>();
or
Mock<IFoo> mockWrapper = new Moq.Mock<IFoo>(MockBehavior.Loose);
Partial Mock IFoo mock = MockRepository.GeneratePartialMock<IFoo>(); Mock<IFoo> mockWrapper = new Moq.Mock<IFoo>() { CallBase = true };

I'm not a fan of this syntax, because it lets you mix methods in ways that don't make sense, like a strict mock that calls it's base methods: Mock<IFoo> mockWrapper = new Moq.Mock<IFoo>(MockBehavior.Strict) { CallBase = true };. It's not clear what will happen in this scenario if I call a method I haven't explicitly mocked, because using two different inputs (a constructor argument and a property) to represent competing concepts leads to confusion. That said, I can tell you what happens: The Strict setting takes precedent and a runtime exception is thrown:

Moq.MockException : Class1.GetFoo() invocation failed with mock behavior Strict. All invocations on the mock must have a corresponding setup.

Passing Constructor Arguments

If you need to pass arguments to the constructor of the class you're trying to mock, there are overloads to allow you to do that.

Rhino.Mocks Moq
IFoo mock = MockRepository.GenerateMock<IFoo>(param1, param2); Mock<IFoo> mockWrapper = new Moq.Mock<IFoo>(param1, param2);
or
Mock<IFoo> mockWrapper = new Moq.Mock<IFoo>(MockBehavior.Strict, param1, param2);

Stubs vs Mocks

Again, from my Using Rhino.Mocks Quick Guide, you may recall that:

A stub is simply an alternate implementation. A mock, however, is more than that. A mock sets up an expectation that

  • A specific method will be called
  • It will be called with the provided inputs
  • It will return the provided results

In Rhino.Mocks, you used the .Stub() and .Expect() extension methods to generate your stubs and mocks directly off your mock object. Moq, on the other hand, uses the .Setup() method on the wrapper object to create both. By default, it will create a stub (no expectation), but if you add Verifiable(), it will generate the expectations (thus, becoming a mock).

For both frameworks, you can explicitly verify stubs, but if you want to do mass verification, you must create the expectations up front.

For Methods:

Rhino.Mocks Moq
Stub mock.Stub(x => x.SomeMethod()).Return(true); mockWrapper.Setup(x => x.SomeMethod()).Returns(true);
Mock mock.Expect(x => x.SomeMethod()).Return(true); mockWrapper.Setup(x => x.SomeMethod()).Returns(true).Verifiable();

Properties are a different story. In Moq, in addition to Mocks that carry expectations, you can generate stubs for properties that basically allow the properties to be set and have them return the values when the getter is called. You can do this for individual properties (and optionally provide an initial value) or you can do it for all properties with a single call using .SetupAllProperties().

Rhino.Mocks, on the other hand, doesn't provide the ability to track property values, so to get that same functionality, you'd need to use a callback (.Do() or .Callback()) and track the value yourself.

For Properties:

Rhino.Mocks Moq
Stub
(always return same value)
mock.Stub(x => x.SomeProperty).Return(true); mock.Setup(foo => foo.SomeProperty).Returns("bar");
Stub
(returns tracked value)
(must use a callback) mock.SetupProperty(f => f.SomeProperty);
Stub w/ initial value
(returns tracked value)
(must use a callback) mock.SetupProperty(f => f.SomeProperty, "bar");
Mock
(always return same value, create expectation)
mock.Expect(x => x.SomeProperty).Return(true); mock.SetupSet(foo => foo.SomePropertyName).Returns("bar");
mock.SetupGet(foo => foo.SomeProperty)

Verifying expectations

The concepts here are pretty similar. You can verify individual call patterns, or (if you created a Mock and not a Stub) you can verify all of the expectations you created in a single pass.

For Methods:

Rhino.Mocks Moq
Called mock.AssertWasCalled(x => x.SomeMethod()); mockWrapper.Verify(x => x.SomeMethod());
Called a specific number of times mock.AssertWasCalled(x => x.SomeMethod(), options => options.Repeat.Times(2) ); mockWrapper.Verify(x => x.SomeMethod(), Times.Exactly(2));
Not called mock.AssertWasNotCalled(x => x.SomeMethod()); mockWrapper.Verify(x => x.SomeMethod(), Times.Never);

For Properties

Rhino.Mocks Moq
Get mock.AssertWasCalled(x => x.SomeProperty); mockWrapper.VerifyGet(x => x.SomeProperty);
Set mock.AssertWasCalled(x => x.SomeProperty = true); mockWrapper.VerifySet(x => x.SomeProperty);
Not called mock.AssertWasNotCalled(x => x.SomeProperty = true); mockWrapper.VerifySet(x => { x.SomeProperty = true; }, Times.Never);

Mass Verification

Moq can do mass verification in two ways. If you have created a mock that sets up expectations using .Expect() in Rhino.Mocks or .Verifiable() in Moq, you can use Moq's .Verify() method to validate just those expectations. Moq also provides a .VerifyAll() method which will validate all of the mocks and stubs you've created with .Setup().

Rhino.Mocks Moq
Verify Mocks only mock.VerifyAllExpectations(); mockWrapper.Verify();
Verify Mocks and Stubs (not available) mockWrapper.VerifyAll();

Controlling Mock Behaviors

Here are some of the general behavior modifications in Rhino.Mocks and their Moq equivalents:

Rhino.Mocks Moq
Change how many times to use the mock use .Repeat():

mock.Expect(x => x.SomeProperty)
.Repeat.Times(2)
.Return(true);
use .SetupSequence():

mockWrapper.SetupSequence(x => x.SomeMethod())
.Returns(true)
.Returns(true)
.Throws( new Exception("Called too many times"));
Ignore arguments use .IgnoreArguments():

mock.Expect(x => x.SomeMethod("param"))
.IgnoreArguments()
.Return(true);
use argument constraints:

mockWrapper.Setup(x => x.SomeMethod(It.IsAny<string>()))
.Returns(true);

Advanced Argument Constraints

Both frameworks provide ways to put advanced constraints on the arguments that trigger a mock. Below are examples -- you'll need to consult the framework documentation for the full list of available constraints.

Rhino.Mocks

 mock.Stub(dao => dao.GetRecordFromDatabase(
                         Arg<int>.Is.GreaterThanOrEqual(0),
                         Arg<decimal>.Is.NotEqual(2.0),
                         Arg<List<string>>.List.ContainsAll(new List<string> { "foo", "bar" }),
                         Arg<object>.Is.NotNull,
                         Arg<object>.Is.Anything))
                 .Return(recordFromDatabase);

Moq

 mockWrapper.Setup(dao => dao.GetRecordFromDatabase(
                         It.Is<int>(i => i >= 0),
                         It.Is<decimal>(d => d != 2.0m),
                         It.IsRegex("[a-d]+"),
                         It.IsNotNull<object>(),
                         It.IsAny<object>()))
         .Return(recordFromDatabase);

Providing a Method Implementation / Using the Input Params

For Rhino.Mocks, in order to provide an alternate implementation, you use the .Do() method to provide a delegate. In Moq, the .Returns() method has an overload that lets you provide a delegate.

Rhino.Mocks

  mock.Stub(dao => dao.GetRecordFromDatabase(0))
                .IgnoreArguments()
                .Repeat.Any()
                .Do((Func<int, ImportantData>)(input => new ImportantData
                {
                    Name = "Orignal Name",
                    RecordId = input
                }));

Moq


            mockWrapper.Setup(dao => dao.GetRecordFromDatabase(It.IsAny<int>()))   
                .Returns((Func<int, ImportantData>)(input => new ImportantData
               {
                   Name = "Orignal Name",
                   RecordId = input
               }));

Throwing an Exception Instead

This is pretty much a drop-in replacement when creating the mock/stub. Where Rhino.Mocks uses .Throw() for this purpose, Moq uses .Throws();

Testing Non-Public Members

With Rhino.Mocks, you can’t mock private or protected members, but you can mock internal members if you add an InternalsVisibleTo attribute for the Castle dynamic proxy assembly. Moq also uses the same proxy, so you'll still need to add the attribute, but Moq has the added benefit of being able to mock protected members. See the Moq Quickstart Guide for details on how to do this.



In this post, I describe how to create class instances and access/set members from other assemblies when their access levels are set to internal or private.

When unit testing, you often need to generate instances of your domain objects within your tests.  Hopefully, these object implements an interface you can mock with Rhino.Mocks (or your preferred mocking tool), or if not, provide virtual members that can be overridden in a derived class by a mocking tool.  But sometimes, you run into a nasty class that makes your life difficult.  I ran into this recently with the MS Dynamics 2011 SDK, where the Entity class, which drives most of the domain objects in the SDK, does not provide an interface, has internal-only setters on it's properties and has an internal-only constructor. And since Rhino.Mocks can't/won't mock non-virtual members, setting values to what you need for your tests is impossible without some work.

Luckily, you can get around internal and private access restrictions using reflection.

Note: I'll post the full set of classes, including some unit tests, at the end of this post, so in my examples here, I'm not going to include the using statements, etc.

Update 5/2/2012: Added Non-Public Fields section; Added base class recursive lookup for private fields/properties.

Non-Public Constructors:

So, let's start with the constructor, since you'll need an object to work with. The issues to deal with here is finding the right constructor based on the parameter list, so I'll use the Type.GetConstructor method.

public static T CreateInstance<T>(params object[] args)
{
    Type typeToCreate = typeof(T);

    Type[] parameterTypes = args.Select(arg => arg.GetType()).ToArray();

    // Use reflection to get the ConstructorInfo object that matches our parameters
    // even if it's not public.
    ConstructorInfo constructorInfoObj = typeToCreate.GetConstructor(
            BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic, 
            null, parameterTypes, null);

    return (T) constructorInfoObj.Invoke(args);
}

To use it, you need only make a call like this:

var entity = MockingHelper.CreateInstance<ClassWithPrivateConstructors>(param1, param2);

Non-Public Properties:

Ok, now you want to set the value of a property where the setter is non-public.  For this, I have a helper method that takes in the name of the property you want to set as a string, however I highly suggest you use the technique I suggested in my previous post for using reflection to get that string, thus limiting your risk of renaming the actual property and breaking your unit tests. This won't work, however, if the member you're trying to reach isn't visible to you, so you may have to resort to string-based names. (see unit tests at end of this post for full examples)

Note that if a member is private and is defined in a base class (ie: not the Type you're actually working with, but one of it's parent types), then you have to recursively walk the type hierarchy until you find what you're looking for.

public static void SetPropertyValue(object target, string memberName, object newValue)
{
    PropertyInfo prop = GetPropertyReference(target.GetType(), memberName);
    prop.SetValue(target, newValue, null);
}

private static PropertyInfo GetPropertyReference(Type targetType, string memberName)
{
    PropertyInfo propInfo = targetType.GetProperty(memberName,
                                          BindingFlags.Public |
                                          BindingFlags.NonPublic |
                                          BindingFlags.Instance);

    if (propInfo == null && targetType.BaseType != null)
    {
        //if the member isn't actually on the type we're working on, rather it's
        //defined in a base class as private, it won't be returned in the above call,
        //so we have to walk the type hierarchy until we find it.
        // See: http://agsmith.wordpress.com/2007/12/13/where-are-my-fields/

        return GetPropertyReference(targetType.BaseType, memberName);

    }
    return propInfo;
}

public static string GetPropertyName<T>(Expression<Func<T>> property)
{
    LambdaExpression lambdaExpression = (LambdaExpression)property;
    var memberExpression = lambdaExpression.Body as MemberExpression ?? 
        ((UnaryExpression)lambdaExpression.Body).Operand as MemberExpression;         
    return memberExpression.Member.Name;       
}

To use it, you need only make a call like this:

var entity = new ClassWithPrivatePropertySetter();
var memberName = MockingHelper.GetPropertyName(() => entity.MyString);
MockingHelper.SetPropertyValue(entity, memberName, "New Value");

Non-Public Fields:

Similar to properties, but a different call off Type:

public static void SetFieldValue(object target, string fieldName, object newValue)
{           
    FieldInfo field = GetFieldReference(target.GetType(), fieldName);
    field.SetValue(target, newValue);
}

private static FieldInfo GetFieldReference(Type targetType, string fieldName)
{
    FieldInfo field = targetType.GetField(fieldName,
                                          BindingFlags.Public |
                                          BindingFlags.NonPublic |
                                          BindingFlags.Instance);

    if (field == null && targetType.BaseType != null)
    {
        //if the field isn't actually on the type we're working on, rather it's
        //defined in a base class as private, it won't be returned in the above call,
        //so we have to walk the type hierarchy until we find it.
        // See: http://agsmith.wordpress.com/2007/12/13/where-are-my-fields/

        return GetFieldReference(targetType.BaseType, fieldName);

    }
    return field;
}

To use it, you need only make a call like this:

var entity = new ClassWithPrivatePropertySetter();
MockingHelper.SetFieldValue(entity, "_myStringField", "New Value");

Putting It All Together:

This is all good and whatnot, but to really make this clean, I would suggest creating some extension classes, or at least a helper class that will make these easier to call for your domain object, if you're going to do any really extensive testing.  For example, I created these extension methods to allow me to set the internal-only Attributes property on the Dynamics EntityMetadata object. These are pretty simple, but I have others that create the entity (which has an internal-only constructor) and set several properties all in one swoop.

public static void SetAttributesViaReflection( this EntityMetadata entityMetadata,
                                                       AttributeMetadata [] attributes)
{
    SetPropertyValue(entityMetadata, 
                     GetPropertyName(() => entityMetadata.Attributes ),
                     attributes);
}

public static void SetOneToManyRelationshipsViaReflection( 
                               this EntityMetadata entityMetadata, 
                               OneToManyRelationshipMetadata [] relationships)
{
    SetPropertyValue(entityMetadata, 
                     GetPropertyName(() => entityMetadata.OneToManyRelationships ),
                     relationships);
}

Good Luck and happy reflecting!

The Full Source Code:

using System;
using System.Linq;
using System.Linq.Expressions;
using System.Reflection;

namespace jwright.blog
{
    internal static class MockingHelper
    {

        public static T CreateInstance<T>(params object[] args)
        {
            Type typeToCreate = typeof(T);

            Type[] parameterTypes = args.Select(arg => arg.GetType()).ToArray();

            // Use reflection to get the ConstructorInfo object that matches our parameters
            // even if it's not public.
            ConstructorInfo constructorInfoObj = typeToCreate.GetConstructor(
                BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic, 
                null, parameterTypes, null);

            return (T) constructorInfoObj.Invoke(args);
        }
  
  

        public static void SetPropertyValue(object target, string memberName, object newValue)
        {
            PropertyInfo prop = GetPropertyReference(target.GetType(), memberName); 
            prop.SetValue(target, newValue, null);
        }

        private static PropertyInfo GetPropertyReference(Type targetType, string memberName)
        {
            PropertyInfo propInfo = targetType.GetProperty(memberName,
                                                  BindingFlags.Public |
                                                  BindingFlags.NonPublic |
                                                  BindingFlags.Instance);

            if (propInfo == null && targetType.BaseType != null)
            {
                //if the member isn't actually on the type we're working on, rather it's
                //defined in a base class as private, it won't be returned in the above call,
                //so we have to walk the type hierarchy until we find it.
                // See: http://agsmith.wordpress.com/2007/12/13/where-are-my-fields/

                return GetPropertyReference(targetType.BaseType, memberName);
            }
            return propInfo;
        }

        public static void SetFieldValue(object target, string fieldName, object newValue)
        {
            FieldInfo field = GetFieldReference(target.GetType(), fieldName);
            field.SetValue(target, newValue);
        }

        private static FieldInfo GetFieldReference(Type targetType, string fieldName)
        {
            FieldInfo field = targetType.GetField(fieldName,
                                                  BindingFlags.Public |
                                                  BindingFlags.NonPublic |
                                                  BindingFlags.Instance);

            if (field == null && targetType.BaseType != null)
            {
                //if the field isn't actually on the type we're working on, rather it's
                //defined in a base class as private, it won't be returned in the above call,
                //so we have to walk the type hierarchy until we find it.
                // See: http://agsmith.wordpress.com/2007/12/13/where-are-my-fields/

                return GetFieldReference(targetType.BaseType, fieldName);
            }
            return field;
        }


        public static string GetPropertyName<T>(Expression<Func<T>> property)
        {
            LambdaExpression lambdaExpression = (LambdaExpression)property;
            var memberExpression = lambdaExpression.Body as MemberExpression ?? 
                ((UnaryExpression)lambdaExpression.Body).Operand as MemberExpression;         
            return memberExpression.Member.Name;       
        }

    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace jwright.blog
{

    public class ClassWithPrivateConstructors : BaseClassWithPrivateMembers
    {
        private ClassWithPrivateConstructors()
        {
            MyString = "parameterless";
        }

        private ClassWithPrivateConstructors(string stringToUse)
        {
            MyString = stringToUse;
        }

        public string MyString { get; set; }
    }

    public class ClassWithPrivatePropertySetter : BaseClassWithPrivateMembers
    {
        public ClassWithPrivatePropertySetter()
        {
            MyStringProperty = "parameterless";
        }

        public string MyStringProperty { get; private set; }
           
        private string _myStringField;
        public string MyStringFieldWrapper { get { return _myStringField; } }
    }

    public abstract class BaseClassWithPrivateMembers
    {
        private string _privateStringField;
        public string PrivateStringFieldWrapper { get { return _privateStringField; } }
           
        private String PrivateStringProperty { get; set; }
        public string PrivateStringPropertydWrapper { get { return PrivateStringProperty; } } 
    }

}
  
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using NUnit.Framework;

namespace jwright.blog
{
    [TestFixture]
    public class UnitTests
    {
        [Test]
        public void VerifyPropertyNamesCorrectlyDetermined()
        {
            var entity = new ClassWithPrivatePropertySetter();
            var memberName = MockingHelper.GetPropertyName(() => entity.MyString);
            Assert.That(memberName, Is.EqualTo("MyString"));
        }

        [Test]
        public void VerifyPropertyValueSet()
        {
            var entity = new ClassWithPrivatePropertySetter();
            var memberName = MockingHelper.GetPropertyName(() => entity.MyString);

            var newValue = "New Value";

            MockingHelper.SetPropertyValue(entity, memberName, newValue);

            Assert.That(entity.MyString, Is.EqualTo(newValue));
        }


        [Test]
        public void VerifyPrivateBaseClassPropertyValueSet()
        {
            var entity = new ClassWithPrivatePropertySetter();
            var memberName = "PrivateStringProperty";

            var newValue = "New Value";

            MockingHelper.SetPropertyValue(entity, memberName, newValue);

            Assert.That(entity.PrivateStringPropertydWrapper, Is.EqualTo(newValue));
        }
  
        [Test]
        public void VerifyFieldValueSet()
        {
            var entity = new ClassWithPrivatePropertySetter();
            var memberName = "_myStringField";

            var newValue = "New Value";

            MockingHelper.SetFieldValue(entity, memberName, newValue);

            Assert.That(entity.MyStringFieldWrapper, Is.EqualTo(newValue));
        }

        [Test]
        public void VerifyPrivateBaseClassFieldValueSet()
        {
            var entity = new ClassWithPrivatePropertySetter();
            var memberName = "_privateStringField";

            var newValue = "New Value";

            MockingHelper.SetFieldValue(entity, memberName, newValue);

            Assert.That(entity.PrivateStringFieldWrapper, Is.EqualTo(newValue));
        }

        [Test]
        public void CreateInstanceTest_NoParams()
        {
            var entity = MockingHelper.CreateInstance<ClassWithPrivateConstructors>();

            Assert.That(entity.MyString, Is.EqualTo("parameterless"));
        }

        [Test]
        public void CreateInstanceTest_WithParam()
        {
            var testString = "a different value";
            var entity = MockingHelper
                             .CreateInstance<ClassWithPrivateConstructors>(testString);

            Assert.That(entity.MyString, Is.EqualTo(testString));
        }
    }
}


After reading my Rhino.Mocks Quick Reference post, a colleague and I had a discussion about the proper way to validate expectations in Rhino.Mocks. Specifically, he questioned if my use of .VerifyAllExceptions() was correct for the ArrangeActAssert syntax, or, as he proposed, is it the "old" syntax, being replaced by the .AssertWasCalled() methods.

Since this is a person I respect, I decided not to smite him and instead took a mental note to do some quick google searches research. Having failed to actually find Ayende's opinion on the matter in the first 5 minutes, I did come across this post, which raised a point I did not realize had forgotten:

In Rhino Mocks, expectations on stubs are not verified; only mocks are verified. If an object is created with GenerateStub instead of GenerateMock, then its VerifyAllExpectations method doesn't do anything. This is non-obvious because the AssertWasCalled and AssertWasNotCalled methods on a stub will behave the way you want them to. In Rhino Mocks, a stub can keep track of its interactions and assert that they happened, but it cannot record expectations and verify they were met. A mock can do both these things. 

So, if you are using a Stub, you must not use .VerifyAllExpectations(), because it will always pass.

Now, one might argue (and many, many on the Internet do argue) that a Stub should not have any expectations, so you shouldn't be calling either method. Stubs are for providing inputs to allow the code under test to run and limit your test to just the code under test, while Mocks are uses to validate behaviour. (they are one of the tests). 

If someone does have a link to Ayende's opinion, please post as a comment or email/tweet me. I'll update this post if I find it.

Update: found this (http://ayende.com/wiki/Rhino+Mocks+3.5.ashx#ExpectExtensionMethod) where it seems Ayende expects people to use either case (ie: he doesn't state here that one is "proper").  I still seem to remember a blog he wrote stating a preference for one over the other, but I haven't yet found it).



This post is a general review of the Rhino.Mocks syntax. While it is intended primarily as a quick reference for myself, I hope anyone who stumbles upon it can also find it useful.

Rhino.Mocks is a .Net mocking framework which is extremely useful for stubbing out objects in your unit tests to ensure you're only testing what you want to test and to allow you to control the environment/state/surroundings under which your tests execute. It is written by Ayende Rahien, the same guy that created nHibernate.  My typical dev unit testing environment would be Visual Studio (C#) + nUnit + Rhino.Mocks. You can either use the nUnit command line tools to run the tests or several good tools that integrate into Visual Studio, such as ReSharper, TestRunner.Net or, my favorite, NCrunch.

For readability, I suggest writing your tests using the Arrange, Act, Assert syntax.

This post is broken into several sections, starting with a general overview and then hitting on several specific use cases of interest:

  • Mock Options
  • Creating a Mock
  • Limiting the Scope of Your Tests
  • Stubs vs Mocks
  • Controlling Mock Behaviors
  • Providing a Method Implementation / Using the Input Params
  • Throwing an Exception Instead
  • Mocking a Property
  • Testing Non-Public Members

The full code for the snippets used in my examples can be found at the end of this posting.

You may also be interested in my posting about Mocking Objects with Restricted Access (internal/private), which has examples of using reflection to manipulate objects that can’t be mocked with Rhino.Mocks.

For additional features, such as raising events in your mock, see the official Rhino.Mocks guide.

Mock Options

Rhino.Mocks supports three basic types of mock objects:

Strict Mock
A strict mock requires you to provide alternate implementations for each method/property that is used on the mock. If any methods/properties are used which you have not provided implementations for, an exception will be thrown.
Dynamic Mock
With a dynamic mock, any methods/properties which are called by your tests for which you have not provided an implementation will return the default value for the data type of the return value.  In other words, you'll get back a 0 for number types, false for Booleans and a null for any object types.
Partial Mock
A partial mock will use the underlying object's implementation if you don't provide an alternate implementation.  So if you're only wanting to replace some of the functionality (or properties), and keep the rest, you'll want to use this.  For example, if you only want to override the method IsDatabaseActive(), and leave the rest of the class as-is, you'll want to use a partial mock and only provide an alternate implementation for IsDatabaseActive().

IMPORTANT: Rhino.Mocks can only mock/stub virtual members of a real class, so make sure the members you care about are virtual -- OR, event better, mock/stub an Interface, in which case you can do whatever you want.

There are also methods for generating Stubs (see “Mocks vs Stubs” section below).

Creating a Mock

To generate mocks, you'll use the static factory Rhino.Mocks.MockRepository. From this factory, you'll create your mock using one of a few generic methods:

  • GenerateMock<T> (for DynamicMocks)
  • GeneratePartialMock<T>
  • GenerateStrictMock<T>

where the T is the class/interface being mocked. The method parameters, if you provide any, will be passed to the object's constructor.

For example:

        var _mockDAO = MockRepository.GenerateMock<IDataAccess>();
        var _mockManager = MockRepository.GenerateStrictMock<IDataManager>(someParam);

As a general rule, I will generate all of my mocks in the test suite [SetUp] method to ensure everything is reset from one test to the next.  You'll see in my test fixture file in the Code Used In Examples section that I have done just that.

Limiting the Scope of Your Tests

Scenario:

I have a BLL object that I want to test, but it relies on a DAL object to fetch/update, etc records from the database. I want to test my BLL object in isolation from the DAL object, so I mock the DAL interface.  

Things to note in this example: I generate a stub for the dao's GetRecordFromDatabase() method so that when it's called with the recordId I care about, it will return my prepared value. This removes the dependency on the DAO layer (which is not even used since I'm mocking an Interface for the DAO) and ensures my test is controlling the inputs and outputs so I'm getting exactly what I want for my specific test condition.

            mockDAO.Stub(dao => dao.GetRecordFromDatabase(myRecordId))
                   .Return(recordFromDatabase);

Code:


    [Test]
    public void TestGetImportantDataAndUpdateTheName()
    {
        //Arrange
        int myRecordId = 100;
        var recordFromDatabase = new ImportantData
                                     {
                                         Name = "Orignal Name",
                                         RecordId = myRecordId
                                     };

        _mockDAO.Stub(dao => dao.GetRecordFromDatabase(myRecordId))
                .Return(recordFromDatabase);

        //Act
        var myRecord = _fancyBL.GetImportantDataAndUpdateTheName(myRecordId);

        //Assert
        Assert.AreEqual(myRecord.RecordId, myRecordId);
        Assert.AreEqual(myRecord.Name, "All Your Base Are Belong To Us");
    }

Stubs vs Mocks

A stub is simply an alternate implementation. A mock, however, is more than that. A mock sets up an expectation that

  • A specific method will be called
  • It will be called with the provided inputs
  • It will return the provided results

So when you setup a mock, you use the syntax .Expect() instead of .Stub().  Then, in your asserts, you can do .VerifyAllExpectations() on your mock to ensure reality matched your expectations.

In this example, the test will fail due to an ExpectationViolationException being thrown due to the Expect(101) not being called.


    [Test]
    public void TestExpectations()
    {
        //Arrange
        int myRecordId = 100;
        var recordFromDatabase = new ImportantData
                                     {
                                         Name = "Orignal Name",
                                         RecordId = myRecordId
                                     };

        _mockDAO.Expect(dao => dao.GetRecordFromDatabase(myRecordId))
                .Return(recordFromDatabase);

        _mockDAO.Expect(dao => dao.GetRecordFromDatabase(101))
                .Return(recordFromDatabase);

        //Act
        _fancyBL.GetImportantDataAndUpdateTheName(myRecordId);

        //Assert
        _mockDAO.VerifyAllExpectations();
    }

Update: see my post for more on VerifyAllExpectations vs AssertWasCalled methods Update: found a posting that I think does a good, simple explanation of Mock vs Stub, including a graphic!

Controlling Mock Behaviors

In the above example, I did _mockDAO.Stub().Return().  This will cause the mock object to return the provided value the first time it's called with the provided inputs.  Sometimes we want to change this behavior, thus the following modifiers can be used between the .Stub() and .Return() calls.

Change how many times to use the stub:

Using the .Repeat.Any(), .Repeat.Once(), .Repeat.Times(10) modifiers:

     _mockDAO.Stub(dao => dao.GetRecordFromDatabase(myRecordId))
             .Repeat.Any()
             .Return(recordFromDatabase);

Return the prepared value regardless of the input value:

Using .IgnoreArguments():

  _mockDAO.Stub(dao => dao.GetRecordFromDatabase(myRecordId))
          .IgnoreArguments()
          .Return(recordFromDatabase);

Advanced Argument Constraints:

You can provide very detailed conditions for when to use your return values by defining per-parameter constraints. For example, here I've said the input must be greater than 0.

       _mockDAO.Stub(dao => dao.GetRecordFromDatabase(Arg<int>.Is.GreaterThanOrEqual(0)))
               .Return(recordFromDatabase);

Here's an example with more than one parameter: (There's a lot more than this – IntelliSense is your friend)


_mockDAO.Stub(dao => dao.GetRecordFromDatabase(
                         Arg<int>.Is.GreaterThanOrEqual(0),
                         Arg<decimal>.Is.NotEqual(2.0),
                         Arg<List<string>>.List.ContainsAll(new List<string> {"foo", "bar"}),
                         Arg<object>.Is.NotNull,
                         Arg<object>.Is.Anything))
         .Return(recordFromDatabase);

Additionally, you can put constraints on properties of objects used as parameters. For instance, if the input parameter had a bool property "IsSomethingICareAbout" and you only wanted to provide a return value when that property is true, you could do this:

            _mockDAO.Stub(x => x.SomeMethod(myObject))
                    .Constraints(Property.Value("IsSomethingICareAbout", true)
                    .Return("foo");

You can put constraints on the input arguments in the same way:


            _mockDAO.Stub(dao => dao.GetRecordFromDatabase(0))
                    .Constraints(Is.GreaterThanOrEqual(0))
                    .Return(recordFromDatabase);

And constraints can be chained with boolean operators:


            _mockDAO.Stub(dao => dao.GetRecordFromDatabase(0))
                    .Constraints(Is.GreaterThanOrEqual(0) && Is.LessThanOrEqual(100) )
                    .Return(recordFromDatabase);

Note: Constraints must be listed in the order of the parameters (ie: the first set of constraints applies to the first parameter, the second set to the second param, and so on).  And a constraint must be provided for each parameter (you can do Is.Anything() as well).

Providing a Method Implementation / Using the Input Params

Instead of using a .Return() with a simple value, you can provide a full implementation of the method using the .Do() method. This also allows you to get access to the input parameters.  If you want, you can define a delegate and just call the delegate.  I prefer to use lamdas unless the method is really long.

So instead of my previous stub for GetRecordForDatabase which pre-configured a return value, I can do it on the fly:

_mockDAO.Stub(dao => dao.GetRecordFromDatabase(0))
                .IgnoreArguments()
                .Repeat.Any()
                .Do((Func<int, ImportantData>)(input => new ImportantData
                                                            {
                                                                Name = "Orignal Name",
                                                                RecordId = input
                                                            }));

Mocking A Property

If you need to mock a property instead of a method, the syntax is pretty much the same:

    [Test]
    public void TestProperty()
    {
        var mockedInterface = MockRepository.GenerateMock<IHasAProperty>();
        mockedInterface.Expect(x => x.StringProperty).Return("fooString");
        Assert.That(mockedInterface.StringProperty, Is.EqualTo("fooString"));
    }

Throwing an Exception Instead

Instead of .Return(), you can use .Throw() to force an exception:


    [Test, ExpectedException(typeof(NullReferenceException))]
    public void TestNeverCallThisMethod2()
    {
        //Arrange
        _mockDAO.Stub(dao => dao.GetRecordFromDatabase(0))
                .IgnoreArguments()
                .Repeat.Any()
                .Throw(new NullReferenceException());
               
        object inputValue = null;

        //Act
        _fancyBL.NullsNotWelcomeHere(inputValue);

        //Assert
        //nothing to do here -- ExpectedException
    }

Testing Non-Public Members

With Rhino.Mocks, you can't mock private or protected members, but you can mock internal members if you do a little extra work.

Specifically, you must allow your test assembly to access internal members of the assembly under test.  This means adding two InternalsVisibleToAttributes to the AssemblyInfo.cs file of the assembly under test: one for the unit test assembly and one for Rhino.Mocks' DynamicProxyGenAssembly2.  If you're using signed assemblies, you must put the full public key in the attribute.

You can get the public key for an assembly by using the sn -Tp yourAssembly.dll command in the Visual Studio Command Prompt.

For example: (no wrapping -- can't be any spaces in the public key)

[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2, PublicKey=0024000004800000940000000602000000240000525341310004000001000100c547cac37abd99c8db225ef2f6c8a3602f3b3606cc9891605d02baa56104f4cfc0734aa39b93bf7852f7d9266654753cc297e7d2edfe0bac1cdcf9f717241550e0a7b191195b7667bb4f64bcb8e2121380fd1d9d46ad2d92d2d15605093924cceaf74c4861eff62abf69b9291ed0a340e113be11e6a7d3113e92484cf7045cc7")]
[assembly: InternalsVisibleTo("jwright.Blog.UnitTesting, PublicKey=00……ec")]

Code Used In Examples

Here are the full code files to use in order to run my example tests:

DataAccessObject.cs

using System;

namespace jwright.Blog
{
    public class ImportantData
    {
        public string Name { get; set; }
        public int RecordId { get; set; }
    }

    public interface IDataAccess
    {
        ImportantData GetRecordFromDatabase(int recordId);
        void NeverCallThisMethod();
    }

    public class DataAccessObject : IDataAccess
    {
        public ImportantData GetRecordFromDatabase(int recordId) 
                                          { throw new NotImplementedException(); }
        public void NeverCallThisMethod() { throw new NotImplementedException(); }
    }

}

FancyBusinessLogic.cs

namespace jwright.Blog
{
    internal class FancyBusinessLogic
    {
        private IDataAccess _dataAccessObject;
        internal IDataAccess MyDataAccessObject
        {
            get { return _dataAccessObject ?? (_dataAccessObject = new DataAccessObject()); }
            set { _dataAccessObject = value; }
        }

        public ImportantData GetImportantDataAndUpdateTheName(int recordId)
        {
            var record = MyDataAccessObject.GetRecordFromDatabase(recordId);
            record.Name = "All Your Base Are Belong To Us";
            return record;
        }

        public void NullsNotWelcomeHere(object input)
        {
            if (input == null) { MyDataAccessObject.NeverCallThisMethod(); }
        }

    }
}

FancyBusinessLogicTest.cs

using System;
using NUnit.Framework;
using Rhino.Mocks;

namespace jwright.Blog
{
    [TestFixture]
    public class FancyBusinessLogicTest
    {
        private IDataAccess _mockDAO;
        private FancyBusinessLogic _fancyBL;

        [SetUp]
        public void SetUp()
        {
            //reset all my objects under test and mocks
            _mockDAO = MockRepository.GenerateMock<IDataAccess>();
            _fancyBL = new FancyBusinessLogic {MyDataAccessObject = _mockDAO};
        }

        //-----
        // Tests will go here
        //-----
    }
}