Question

I want to create an IList of objects that are all different concrete types, so:

var tasks = new List<ITask>();
foreach (string taskName in taskNames)
{
    var task = MockRepository.GenerateStub<ITask>();
    task.Stub(t => t.Name).Return(taskName);
    tasks.Add(task);
}
return tasks;

The problem is that each stub object is all the same concrete type. Normally this is fine, but I have a case where I want to test each one being a different type. Can I somehow configure Rhino Mocks to do this, in this case?

EDIT:

The “you-must-be-doing-it-wrong-crew” are out in force today. Since you all seem to think I need to justify my use-case before you can take a stab at answering my question, here’s what I’m doing:

• ITask is in my domain model, so it’s part of my business layer.
• I have logic in a higher level (presentation) layer that takes an ITask as an argument.
• The presentation layer logic normally executes a default Strategy on the ITask, but there can be special cases where we need to use a different Strategy, and the Strategy to use depends entirely upon the concrete type of the ITask object.
• The regular Strategy pattern doesn’t work here because that requires my concrete ITask objects to know about a layer above them.
• Decorators still have to know about the concrete type of the object they decorate, and have to be applied either at construction time (wrong layer for this case) or when used, but then that leaves me with the same problem – applying a decorator based on concrete type.
• I decided to use the same pattern used by DataTemplates (and the DataType attribute) in WPF. That is, given an object from a lower layer, see if anyone’s registered a Strategy to handle that type, and if so, use it. Otherwise, use a default Strategy.

So, I hope you can see why I need the test logic. So far I’ve had to write my own Stub factory that generates from a limited pool of concrete ITask types. It works, but I’d rather let Rhino Mocks do it for me.

Answer 1

You could add a ITask.Type property.

The code which is interested in the type behind the interface should then use this property instead of calling GetType(). In your tests, it then becomes trivial to take control of what the Type property returns for any given ITask stub.