views:

50

answers:

1

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.

+3  A: 

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.

Wim Coenen
True. Right now I'm just comparing based on TaskName, which is ultimately a static string in a static class. If I do what you're describing, I have to unit-test each implementation of ITask to make sure it returns its own type as the Type property. Seems a bit smelly, but it would work.
Scott Whitlock
@Scott Whitlock: I think the smelliness (code which makes decisions by inspecting the type of objects) was already there and is just being made explicit this way. A fix for the original smell would require more information on why you need to inspect the type.
Wim Coenen
@Wim Coenen: I've added more explanation to my question, as requested.
Scott Whitlock
@Scott Whitlock: ah.. I've also encountered this problem where you want to associate extra information with objects in the UI layer, without making them aware of the UI. I've considered using the visitor pattern for this but it feels like swatting a fly with a FN P90. Sorry for doubting you ;-)
Wim Coenen