3

I am using Unity for IOC. I would like to configure the creation of moq objects using the app.config. My config looks some like this:

<unity xmlns="schemas.microsoft.com/practices/2010/unity">
  <container>
    <register type="Namespace1.IFoo, FooInterface"                   
              mapTo="Namespace2.FooImp, FooImplementation">
    </register>
</container>
</unity>

I am looking for a technique to specify a configuration some like this:

<unity xmlns="schemas.microsoft.com/practices/2010/unity">
  <container>
    <register type="Namespace1.IFoo, FooInterface"                   
              mapTo="Moq.Mock<IFoo>, Moq">
    </register>
</container>
</unity>

I Know that I have to access .Object property of a Mock but this sample is just meant to explain what I want to do.

In other words: I do not want to use code to configure unity to use moq. An option would of course be to create some helpers that can be used in general.

Jaster
  • 8,255
  • 3
  • 34
  • 60
  • 1
    Do you want Moq to create instances of every object created by the container or just for specific instances? How do you verify the calls to the mocks were made? How do you setup return values of the mocks? – Sebastian Weber Mar 06 '12 at 13:20
  • I want to do it with specific types. I do not want to replace the unitycontainer by a mock container. I would do setup and verification by limiting the lifetime of mocks to singleton. – Jaster Mar 06 '12 at 13:28
  • So you would like to register `Mock` with a singleton lifetime via config, tell the container that you want to use `Mock.Object` as the implementation for `IFoo` also via config and then you setup expectations and return values for your mocks (which you would have to resolve from the container first) via code? – Sebastian Weber Mar 06 '12 at 14:00
  • 3
    Why would you want to do something like this? – Mark Seemann Mar 06 '12 at 14:16
  • @SebastianWeber exactly. The reason is pretty simple: sometimes you just want to disable a component without the need to verfy calls, etc. – Jaster Mar 06 '12 at 15:11
  • @Jaster Sorry but that sounds like you create a problem where there is none. You have to do some setup in code anyway. I'd say do the part that involves Moq there too. You can register the whole set of dependencies in your config if you think you have to. And overwrite the mocked ones before the test run. – Sebastian Weber Mar 06 '12 at 17:50
  • @SebastianWeber Why would you always ask for the "why"? I do not want to describe the whole issue - neither I need to. I am just looking for ideas to solve a very concrete problem. I have reduced it to a very basic example, so please do not question my intentions. I appriciate input about the issue but not about the concept behind it. No offence. – Jaster Mar 07 '12 at 13:02
  • @Jaster Your scenario suffers from a lot of friction with Unity's config engine.Friction is an indicator that you are trying to do something you should avoid.The XML configuration of Unity is not up to that task.You can't do anything about it.By repeatedly asking about the "why" I was looking for an alternative approach to the problem. – Sebastian Weber Mar 07 '12 at 13:12
  • Thats the point. I know/have alternatives, but I do not want them. I want to solve it via XML. – Jaster Mar 07 '12 at 13:25

1 Answers1

1

After no one could help I figured something out.

Use a Factory for moq and add a factory resolution via unity

sample goes here

Community
  • 1
  • 1
Jaster
  • 8,255
  • 3
  • 34
  • 60