Question

I’m trying to test a class that instantiates objects dynamically and stores them in a collection. Because I need to test logic that instantiates them and operations on those objects, I thought it would be a great idea to create a helper fake factory class that could be injected for testing. Here’s what I came up with

public class RhinoFakeFactory<TFakeable> where TFakeable : class
{
    public List<TFakeable> Fakes { get; set; }
    public FakeType FakeTypeToCreate { get; set; }

    public TFakeable GetFake()
    {
        TFakeable fake = default(TFakeable);

        switch (FakeTypeToCreate)
        {
            case FakeType.None:
            case FakeType.Stub:
                fake = MockRepository.GenerateStub<TFakeable>();
                break;
            case FakeType.DynamicMock:
                fake = MockRepository.GenerateMock<TFakeable>();
                break;
            case FakeType.DynamicMockWithRemoting:
                fake = MockRepository.GenerateDynamicMockWithRemoting<TFakeable>();
                break;
            case FakeType.StrickMock:
                fake = MockRepository.GenerateStrictMock<TFakeable>();
                break;
            case FakeType.StrickMockWithRemoting:
                fake = MockRepository.GenerateStrictMockWithRemoting<TFakeable>();
                break;
            case FakeType.PartialMock:
                fake = MockRepository.GeneratePartialMock<TFakeable>();
                break;
        }

        Fakes.Add(fake);
        return fake;
    }

    public RhinoFakeFactory()
    {
        Fakes = new List<TFakeable>();
    }
}

public enum FakeType
{
    None,
    Stub,
    DynamicMock,
    DynamicMockWithRemoting,
    StrickMock,
    StrickMockWithRemoting,
    PartialMock
}

After I wrote it, I then thought “I can inject this just fine but now I have to reference my test project and namespaces”. This doesn’t sit well with me. Maybe because I’m new to unit testing and trying to stick to convention as much as possible. From what I understand, the test code should be mostly transparent to code being tested so that could can keep as much focus and clarity on what it is trying to accomplish as possible.

Should I stop worrying and just use my fake factory? I would like to because it generates fakes as I need them for instances like the one I described above and because I can access the instantiated fake objects in the Fakes property to check their state. Is there something else implemented or possibly something in the Rhino Mocks framework that already takes care of this situation?

Answer 1

It sounds like your class is instantiating objects dynamically (possibly within some logic construct like a switch statement?) and you want to allow for the testing of this with your FakeFactory?

Using the FakeFactory and having your class under test know about test code is a big code smell, indicating overly tight coupling as well as introducing an unnecessary concern to your class (in fact, the dynamic instantiation is already an unnecessary concern).

What you should do is introduce the factory pattern as the way you get your dynamic objects, and have an interface over your factory which allows you to replace it using RhinoMocks. Then when you configure your Mock objects, you can tell the factory to return another Mock as needed.

So your class will end up looking something like this:

public class ClassBeingTested
{
    private IFactory _yourFactory;

    public ClassBeingTested(IFactory yourFactory)
    {
        _yourFactory = yourFactory;
    }

    public MethodWithDynamicInstantiation()
    {
        IClass = _yourFactory.GetClassDynamically(someparam);
    }
}

I’ve not used RhinoMocks in years so won’t attempt some code, but with this pattern you minimize the knowledge your class has about the dynamic instantiation logic while also providing the place to hook in the mocks of the dynamic objects and additionally removing any knowledge of testing code.