How to Mock a class which has private Constructor using Rhino Mocks

Question

I am using Rhino Mocks 3.6

i have a class "Configuration.cs" which has a private constructor (i did it for the Singleton implementation). Now i want to mock this class (Partial Mock) but i am not able to do it. Error:

Can not instantiate proxy of class: Efi.CrmIntegration.MonarchServices.Utilities.Configuration. Could not find a parameterless constructor. Parameter name: constructorArguments

Whats the solution for the same.

Answer 1

Static singletons are difficult to mock and to test, and should be avoided, ideally. As RhinoMocks has pointed out, you can't make a partial mock of your Configuration singleton, but you have some options.

1. Make your private constructor public. This should be considered a quick hack, though. There are much better ways of doing this.

2. Change how your singleton is instantiated. Give your Configuration class an interface, let's say IConfiguration. You probably already have a static Instance property on Configuration. Change it's type to be IConfiguration, and give it a public setter. In your unit tests, mock or stub IConfiguration, and set the Configuration.Instance property to that. This is still something of a hack (but it is useful when you have lots of classes that are already using the singleton, and you don't have time to implement the next option).

3. Use dependency injection. Give your Configuration class an interface, again let's say IConfiguration. Classes that have a dependency on the Configuration singleton should be changed to take an IConfiguration parameter in their constructor. When you create an instance of one of these classes, you inject in the singleton instance of Configuration. When testing, make a mock or stub of type IConfiguration, and pass that to the classes instead. You can improve on this with a dependency injection framework, like Castle Windsor or Ninject, which you could probably use to do away with your need for a static singleton altogether.

I highly recommend you change your design and use option 3 (with a dependency injection framework, if possible).