I’ll look into the email comments. It looks like for now all I have is comments RSS.

I think the Controller might be a special case of state/interaction testing. Since it’s a base class I don’t own, I’d almost consider it a different object.

I’ve also run into this where we had a different team implement our base business objects. Setting property values would do all sorts of things which we didn’t know and didn’t care about. So we just made sure we did what we were supposed to do and let the underlying object do its work.

My benchmark here was that I had no way to make the connection between the operation “Redirect” and the resultant state “Response.RedirectedTo”. Admittedly the connection between the two seems logical, but how do I know the connection exists? I have to know the underlying base class does this.

The way we arrived at this solution was that we instantiated our controller, called “Redirect”, and saw we got exceptions. PrepareController fixes these exceptions, but for us, that we got exceptions was enough for us to stop, subclass and redirect, and use the mocks to test the interaction between our derived class and the base class.

I wouldn’t go as far as to recommend people against PrepareController, but it’s just my personal preference to treat base classes I don’t own as an black-box dependency WRT methods.

As an aside, it’s not good to test “inner details” but OK to test public state. And interaction testing is meant for that, object interactions, i.e. there are mo than one object, e.g. your controller. Currently, you test how you interact with yourself

P.S. Could you please look into enabling e-mailing responses for comments? It’s just not convenient to go here once in a while to check discussion.

Yes, it is just a matter of personal taste, but I only really apply this to base classes I don’t control. I don’t control SmartDispatcherController, and I don’t want to know how its operations change its state. All I care in my test is that “Redirect” is called. That is also a method I don’t own, so I don’t want to test what it does.

What the Redirect method does is not important. That it is being called is important. I only care about the interaction, not the final state that MonoRail sets up for me.

In the end, if I cared what “Response.RedirectedTo” was, I would look at that. But I don’t in these tests. All I care about is “did I call Redirect with XXX controller and YYY action”.

Personally, I feel like you are complicating the test by making it interaction based as opposed to simpler state based. Don’t you try to abstract too much away?

You just need a couple of helper methods, like Sean shows, if any. If they were on a Response would it hide “implementation details” enough?

Maybe I’m being paranoid, but it feels weird for MonoRail implementation details to leak into my tests. I find it more comforting to just do a partial mock of one method instead of getting a bunch of scaffolding up for a controller.

I run into this often when I test a derived class where I don’t own the base class. I tend to treat the base class as a black box.

protected void AssertRedirectedTo(string controller, string action, string queryStringParameters)
{
Assert.AreEqual(Response.RedirectedTo, string.Format(@”/{0}/{1}.rails{2}”, controller, action, queryStringParameters), “RedirectedTo was not equal”);
}

There may be an easier way to do this, but this has worked for me thus far.