Develop Reference

AutoFixture AutoMoq Cast a mocked object as an interface

I hope someone can give me some ideas.
I need to create a mocked object that satisfies the following:
It implements the interface IEntity.
It uses the base implementation I already have in EntityBase.
The properties are auto generated with AutoFixture.
I have tried several alternatives and I ended with this code:
fixture.Customize(new AutoConfiguredMoqCustomization());
fixture.Customize<IEntity>(c => c.FromFactory(
() => fixture.Create<Mock<EntityBase>>().As<IEntity>().Object));
However, I obtain the following exception:
Mock type has already been initialized by accessing its Object property. Adding interfaces must be done before that. :(

You could use a TypeRelay to tell AutoFixture that requests for IEntity should be satisfied by creating instances of EntityBase:
fixture.Customizations.Insert(0, new TypeRelay(typeof(IEntity), typeof(EntityBase)));
Now, every time AutoFixture has to create an instance of IEntity, it will instead create an instance of EntityBase which, in turn, will be handled by Moq thanks to the AutoConfiguredMoqCustomization.
Relays are pretty handy and there are a few of them built-in. In fact, they enable the whole auto-mocking functionality by relaying requests for interfaces and abstract classes to a mocking library.

Stubbing a method which is called in class constructor in RhinoMocks

My class has a method like this:
internal virtual Something CreateSomething(){...}
It was done this way so that in testing I can stub CreateSomething() to return a mock object:
var something = ...; //some mock object
var t = MockRepository.GenerateStub<MyObject>();
t.Stub(x => x.CreateSomething()).Return(something);
This worked fine but now CreateSomething() is called in the class constructor, before it was called later on, so by the time I stub the method my object is already created.
Is there a workaround that doesn't involve changing the design, to pass stub methods in at construction time? If not I can consider changing the design to use construction-injection (which I'm sure some of you are itching to suggest anyway!) but I'd rather see if Rhino supports this use-case first.

There is no way to stub the method before it is invoked from its class constructor. This is C# limitation. And this is reasonable.
In general it is a bad practice to call virtual method from the constructor, because likely the result will not be what is expected. See details here: Virtual member call in a constructor.
So, I highly recommend to either make this method non-virtual, or avoid its invocation from the constructor.
Anyway in such situation it won't work as virtual.
Regarding you question about testing the method, which is called from constructor.
I presume, this is a private method. Otherwise it could be tested as a regular public method.
As it is private, then there is no need to test this particular method in isolation. I recommend to follow general approach in testing constructors and testing private methods: Do not test private methods.
Test the public visible effect instead. That could be:
Public property initialization
Mocked dependencies invocation or properties access
Exception thrown
etc.
Please also find more details about this topic by the links below:
Is it important to unit test a constructor?
Unit testing private methods in C#

Using Autofac and Moqs with Delegate Factories

I am trying to unit test a class that uses factory injection. I have a class that instantiates two copies of the same object (with different config) to control hardware. I'm trying to test the behaviour of the classes while simulating the hardware calls.
I've injected a set of factory delegates into the constructors so that the class can instantiate the hardware classes as required. However I just can't work out how to control or create factory methods within the Autofac.Extras.Moq package. It seems that this functionality isn't supported in the package.
I'm looking for an equivalent call to :
mock.Provide<IHWController>(//created by factory delegate)
I want to create a specific mock object with behaviour, based on the parameters used to instantiate the HWcontroller. Is what I'm trying to do even possible?
class SystemUnderTest
{
SystemUnderTest(Ia a, Ib b, Ic c,
/** 15 other things **/
Func<Func<Uri, IHwController>, HwType, IHwManager> HwManagerFactory,
Func<Uri, IHwController> HwControllerFactory)
{
}
}
class HwManager()
{
public Func<HwType, Func<Uri, HwController>, HwManager> Factory;
public HwManager(HwType type, Func<Uri, HwController> ControlFactory)
{
//Constructor
}
}
The code I'm unit testing creates Managers of controllers. The controller is the hardware layer, but I'm testing complex (coupled) behaviour inside the manager. Therefore, I'm trying to work out how to mock the Func<Uri, HwController> ControlFactory so that it returns my setup mock objects so that I can probe the behaviour of the manager.
My system under test creates a concrete instantiation of the HWManager. I realise in a perfect scenario I would test the HwManager and SUT separately, but I'm specifically testing the integration of the two components.
I'd like to configure the autofac to control the delegate factory. If this isn't possible, then I can manually setup the SUT, but then I don't get any value from the autofac helper.

I usually just create a Func that returns my mocked instance e.g.
var controller = mock.Provide<IHWController>();
var manager = new HwManager(something, (uri) => controller);
If the factory is expressing "given a Uri I will provide a controller", the lamda in my example above satisfies that statement.
As an aside, you should express your factories using interfaces, not concrete classes. It makes it a lot harder to unit test when the factories are producing concrete classes instead of interfaces (which can always be mocked) e.g.
// IHwController is the product of the factory instead of HwController
public HwManager(HwType type, Func<Uri, IHwController> ControlFactory)

If anyone gets stuck on this in the future, the key is to create a func that matches the constructor func, customised to provide the appropriate mocks on each invokation (e.g. via an internal counter).
You can then use the mock.Provide() syntax, providing a func that matches the constructor func with your created func above. This will then be invoked correctly allowing you to control the mocks appropriately.

Ninject Factory NamedLikeFactoryMethod not working as directed?

NamedLikeFactoryMethod in Ninject Extensions Factory working in non-compliance with documentation
I am basically trying to do what the above post has listed but I guess the API has changed, When I look in the object browser I do not see an overload that would allow for this syntax.
I am trying the code below, I is making me use a NamedLikeFactoryMethod but when I do that it complains about the Bind<>.To<> portion, and either way I am unable to pickup the interface type to call the Create[Name] methods. Has this changed?
I am using Ninject 3, with the Ninject.Extension.Factory 3
Factory
public interface ITemplateProcessorFactory
{
ITemplateProcessor CreateXsltProcessor();
ITemplateProcessor CreateRazorProcessor();
ITemplateProcessor CreateMarkdownProcessor();
}
Binding
Bind<ITemplateProcessor>().To<XsltProcessor>().NamedLikeFactoryMethod((ITemplateProcessorFactory)t => t.);
Bind<ITemplateProcessor>().To<XsltProcessor>().NamedLikeFactoryMethod<ITemplateProcessor,ITemplateProcessorFactory(t => t.);

You have to name your methods GetXXX otherwise the factory will request instances without using a name.

Mocking the is operator in Moq

Is there a way to get my mocks to impersonate a type? I am trying to do something like this:
var myMock = new Mock<IMyType>();
myMock.Setup(x => x.GetType()).Returns(typeof(MyTypeImpl));
however, GetType is not overrideable.
Any suggestions?

I know this is an old post, but I was searching for a solution to this issue...
Using Moq it is possible to add the standard GetType signature to your interface, allowing Moq to mock the method, without the need for writing any more code as the method is already implemented for you.
Type GetType();

Instead of using the is operator to check types, you could (not should) implement your own overridable interface method that performs a similar function, and implement it with the is operator (or typeof()/GetType()) on your usual bunch of classes.
That said, if you're using the is operator in a way that needs to be testable like this, it's more likely than not that you're basically defeating the purpose of polymorphism and interfaces somewhere along the line. I'd think about whether I could just get rid of it.