views:

131

answers:

3

I'm trying to mock a class from the Microsoft Sync Framework. It only has an internal constructor. When I try the following:

var fullEnumerationContextMock = new Mock<FullEnumerationContext>();

I get this error:

System.NotSupportedException: Parent does not have a default constructor. The default constructor must be explicitly defined.

This is the stack trace:

System.Reflection.Emit.TypeBuilder.DefineDefaultConstructorNoLock(MethodAttributes attributes)
System.Reflection.Emit.TypeBuilder.DefineDefaultConstructor(MethodAttributes attributes)
System.Reflection.Emit.TypeBuilder.CreateTypeNoLock()
System.Reflection.Emit.TypeBuilder.CreateType()
Castle.DynamicProxy.Generators.Emitters.AbstractTypeEmitter.BuildType()
Castle.DynamicProxy.Generators.ClassProxyGenerator.GenerateCode(Type[] interfaces, ProxyGenerationOptions options)
Castle.DynamicProxy.DefaultProxyBuilder.CreateClassProxy(Type classToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options)
Castle.DynamicProxy.ProxyGenerator.CreateClassProxyType(Type classToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options)
Castle.DynamicProxy.ProxyGenerator.CreateClassProxy(Type classToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options, Object[] constructorArguments, IInterceptor[] interceptors)
Castle.DynamicProxy.ProxyGenerator.CreateClassProxy(Type classToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options, IInterceptor[] interceptors)
Castle.DynamicProxy.ProxyGenerator.CreateClassProxy(Type classToProxy, Type[] additionalInterfacesToProxy, IInterceptor[] interceptors)
Moq.Mock`1.<InitializeInstance>b__0()
Moq.PexProtector.Invoke(Action action)
Moq.Mock`1.InitializeInstance()

How can I work round this? I'm fairly new to Moq.

+1  A: 

I am not really an expert on Moq, but I think you need to specify the arguments for the constructor. In Rhino Mocks you would specify them like this:

var fullEnumerationContextMock = new Mock<FullEnumerationContext>(arg1, arg2);

It is probably similar in Moq.

Grzenio
Can anyone confirm if this is possible with Moq? I'm using Moq 3.1
tjrobinson
+1  A: 

You cannot mock a type that does not have a public constructor because Moq will not be able to instantiate an object of that type. Depending on what you are trying to test, you have a few options:

  1. If there's a factory object or some other way of obtaining instances of FullEnumerationContext perhaps you can use that (sorry, I'm not familiar with the sync framework)
  2. You could use private reflection to instantiate a FullEnumerationContext, but then you would not be able to mock methods on it.
  3. You could introduce an interface and/or wrapper object that's mockable that the code under test could invoke. The runtime implementation would delegate to the real FullEnumerationContext, while your test-time implementation would perform whatever action you need.
marcind
A: 

Based on the answers from marcind I've created an interface (IFullEnumerationContext) which I mock and then I've got two overloads of the method I am trying to test, one that takes the FullEnumerationContext and another that takes IFullEnumerationContext. It doesn't feel great, but it does work. Any better suggestions or improvements would be welcome.

public override void EnumerateItems(FullEnumerationContext context)
{
    List<ItemFieldDictionary> listItemFieldDictionary = EnumerateItemsCommon();
    context.ReportItems(listItemFieldDictionary);
}

public void EnumerateItems(IFullEnumerationContext context)
{
    List<ItemFieldDictionary> listItemFieldDictionary = EnumerateItemsCommon();
    context.ReportItems(listItemFieldDictionary);
}
tjrobinson
I think it would be better if the overload that takes `FullEnumerationContext` wrapped the context instance in a `FullEnumerationContextWrapper` and then passed that into the overload that accepts `IFullEnumerationContext`. That way only one of these methods would contain all the important code. The other one would be a one-line statement that does not need to have a unit test associated with it.
marcind