i really like this approach and it works great, thx

By using another abstract class you don’t have to implement anything while you can still access the ‘DoSomethingSpecific()’ method, because your test is inside an inner class of ‘MyAbstractTestClass’…


public abstract class MyAbstractTestClass : MyAbstractClass
{
[TestFixture]
public class InnerTestClass
{
[Test]
public void CallsProtectedAbstractMethod()
{
var mocks = new MockRepository();
var myObject = mocks.DynamicMock();

myObject.DoSomethingInteresting();
myObject.VerifyAllExpectations();
}
}
}


Maybe an Expect method that takes a string and an isolation level as input would be a more feasible track for this type of scenario.


myObject.Expect("DoSomethingSpecific", MethodIsolation.Protected);


Upside is the compiler doesn’t need to know about it at all and DoSomething can stay abstract and protected. Downside is that you’d have to work with string literals.

still not sure if you could get that to work though… it changes the public interface of the type being mocked, so you have to get the compiler to recognize the modified interface as well. And since the type is generated at runtime, it’s probably gonna be hard to get the new interface to be recognized at compile time

Ofcourse, the mocking framework could add a postfix to those methods (e.g. DoSomethingSpecific_()) but that would mean an extra ‘convention’. Maybe the the MethodBinding could provide some flags/insights into how the framework pre-/postfixes the protected methods. So you can expose that ‘convention’ into your code making it a bit clearer… for example:


var mockMethodBinding = mocks.ProtectedToPublicBinding();
mockMethodBinding.ProtectedMethodNames.PostFix = '_protected';
var myObject = mocks.DynamicMock(mockMethodBinding);
myObject.Expect(m => m.DoSomethingSpecific_protected());


I agree. Neither is ‘better’ but i prefer a dumb flag implementation above altering the isolation level of DoSomethingSpecific().

Maybe something like this would do the trick (doesn’t work, but illustrates the idea):

var mockMethodBinding = mocks.ProtectedToPublicBinding();
var myObject = mocks.DynamicMock(mockMethodBinding);
myObject.Expect(m => m.DoSomethingSpecific());


This is just a general idea…

This is one of those cases where each possible solution takes less than 5 minutes to implement, yet the discussion of what is the best approach could linger on for a long time

You want to test DoSomethingSpecific()? Then isolate it in a seperate class and test that one. (cfr. David)

You want to test a specific implementation of MyAbstractClass? Then use that one in your test (probably will end up in SlowTests ) (cfr. Simone)

You want to test if MyAbstract correctly fires the DoSomethingSpecific() method (can’t see why you would want to do that in this case but who knows…)? Then write your own flagging implementation and assert on it…

that’s a good post

@Peter:

i don’t really see how making it a partial method would solve this problem? Multiple derived classes from the abstract class should be possible, and partial methods don’t really help there as far as i know

@Simone:
Good point
but what if the base class doesn’t really hold any state to assert on? Let’s use my Disposable class as an example (http://davybrion.com/blog/2008/06/disposing-of-the-idisposable-implementation/). What i really want to cover in a test, is that when someone calls the Dispose method, the protected abstract methods are called properly. The sole purpose of this class is to provide an easy implementation of the IDisposable pattern… to test that, your test pretty much has to know about the implementation. Now, i could write my own class that inherits from the Disposable class and i can make it set a flag when the abstract method is called and then in the test i could assert on the flag value. But then the test is still coupled to the implemention of the original code, only more indirectly.

Before I edited it, I was rambling on about how even when it seems over-the-top, generally when I have trouble testing something I find refactoring to avoid the problem pays off in the long run.

More rambling on this topic here: http://tinyurl.com/6avqej

But if the implementation is more like a one-liner or at least something very simple (yet very important) then this approach feels a bit over-the-top to me