Bruno Peeters Technical Blog

RhinoMocks is a framework for creating mocked instances, that can be used within unit tests. Since the framework is not to be maintained anymore (last version was in 2010), you can’t use RhinoMocks for example within .Net Standard or .Net Core projects.

A project I was working on was having the same struggle; we had quite a large set of unit tests that where using RhinoMocks. For several reasons, we decided to migrate our projects to .Net Core, which made it impossible to use RhinoMocks anymore. We decided to switch to the Moq framework. In this blog I summed up the most used RhinoMocks constructions and how to port them to Moq.

There are different levels of testing a programmer can do, the must read Code Complete differs the following types of tests: unit testing, component testing, integration testing, regression testing and system testing. The terms unit testing and component testing are quite confusing to most people.

Within unit testing you use stubs and mocks to test directly your code. The code is tested in isolation. Typical things you want to stub are hardware, networks or databases.

Component level testing is situated at a higher level. You remove the stubs and mocks and test your code against the real thing. So you remove the stubbed hardware interface and put a real device to the test.

Within the field of unit testing, we use “mock objects” (see also one of my previous posts) and “stubs” to help us testing our classes. For example when having a class which writes directly to a piece of hardware, and you want to write a unittest for it, you have to create some stand-in class which operates like this device. This is needed since the device isn’t really there when running the tests on a build machine. Also, we probably want to force our device in some state or want to get rid of time constraints. Since many people actually don’t know the difference between a stub and a mock, you can take the following rule of thumb about the difference between mocks and stub:

• With mocks you can control the flow of your object. You can for example call a mock instance which will react the same as if you would interface with a real piece of hardware but without the need of the hardware of having to deal with time constraints.  With a mocking framework you are be able to influence the behavior of the object you have mocked.
• Stubs normally return a default value. For example they return always true when calling a method which has a return value.

So in short: if you won’t want to control the behavior of your object, you want to write a stub. Otherwise you write a mock object for your unittest.

DynamicMock myExampleMock = new DynamicMock(typeof(IMyExample)); // Creates a mock object from the defined interface

myExampleMock.ExpectAndReturn(“AmethodName”, // the method name
“abc” // return value
Null  // expected arguments);

IMyExample myExampleInstance = (IMyExample)securityTokenServiceMock.MockInstance;