Comments on: Mocking Dilemma, Solved!

By: Davy Brion

Davy Brion — Tue, 22 Jul 2008 12:48:12 +0000

don’t worry Rob, Moq is still on my TODO list

along with a bunch of other things unfortunately :s

By: Dew Drop - July 22, 2008 | Alvin Ashcraft's Morning Dew

Dew Drop - July 22, 2008 | Alvin Ashcraft's Morning Dew — Tue, 22 Jul 2008 12:00:33 +0000

[...] Mocking Dilemma, Solved! (Davy Brion) [...]

By: Rob

Rob — Tue, 22 Jul 2008 11:43:52 +0000

Moq has a support for protected methods. You can’t use lambdaexpressions with protected methods, but at least it’s supported.

By: Davy Brion

Davy Brion — Tue, 22 Jul 2008 10:55:32 +0000

don’t get me started on regions

By: Jan Van Ryswyck

Jan Van Ryswyck — Tue, 22 Jul 2008 10:52:36 +0000

It wouldn’t matter for simple scenarios (e.g. on or two template methods). You can always hide the dirt behind a region . For more complex scenarios, Tom’s approach seems more feasible.

By: Davy Brion

Davy Brion — Tue, 22 Jul 2008 10:37:03 +0000

letting the fixture inherit directly from the abstract class would require the fixture to implement the abstract method. which i didn’t like

By: den ben

den ben — Tue, 22 Jul 2008 10:21:51 +0000

@Jan: I see that now (sorry for not reading your comment in depth first). And that “self shunt” pattern wouldn’t even need a mock at all to be able to do the test (like you said)… which is probably what I would have done. However, I agree that Tom’s solution is the cleanest

By: Jan Van Ryswyck

Jan Van Ryswyck — Tue, 22 Jul 2008 10:02:26 +0000

@Den Ben: Kinda what I meant by using the “self shunt” pattern. Seeing the code and all, it looks nicer this way.

By: den ben

den ben — Tue, 22 Jul 2008 09:50:43 +0000

ohw.. and the comment dit not allow me to post the
var myObject = mocks.DynamicMock(); correctly

you need to pass the MyAbstractClassTests type instead of the MyAbstractClassTestWrapper type

By: den ben

den ben — Tue, 22 Jul 2008 09:47:44 +0000

Fantastic solution!

But I’m wondering… wouldn’t it be enough to do it as follows:

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

myObject.Expect(m => m.DoSomethingSpecific()); // <= no more compile error

myObject.Replay();

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

Won’t this also work? And if not, what am i missing?

By: Jan Van Ryswyck

Jan Van Ryswyck — Tue, 22 Jul 2008 07:08:39 +0000

One could also choose for the “self shunt” pattern, where the test fixture itself derives from the abstract base class. This has the disadvantage of being less readable when continuing to use Rhino Mocks for checking whether the abstract method is called. If simplicity is all you need, then no mocks are needed and a simple boolean member variable will do. If the scenario, is more complex, than this is a nice and clean solution.

Kind regards,

Jan