Davy Brison writes about mocking dilemma
Basically the question he deals with is how to test this code:
8 public abstract class MyAbstractClass
9 {
10 public void DoSomethingInteresting()
11 {
12 // some stuff would go here…
13 DoSomethingSpecific();
14 // more stuff would go here…
15 }
16
17 protected abstract void DoSomethingSpecific();
18 }
The problem here is that we want to mock DoSomethingSpecific but using other mock frameworks we can’t mock protected and private methods.
Davy writes:
“If I want to use a mocking framework for this, I have two options (that I can think of right now): I either make the abstract method public so the above code would compile, or I can make it protected internal and then allow my internal members to be visible to my Test project. I dislike both approaches”
With Typemock Isolator we can keep our design and mock DoSomethingSpecific using reflective
mocks. Reflective mocks allows you to mock private and protected methods.
Here is how to solve the issue with Typemock Isolator:
19 [Test]
20 public void CallsProtectedAbstractMethod()
21 {
22 MockObject mockObject = MockManager.MockObject<MyAbstractClass>();
23 mockObject.ExpectCall(“DoSomethingSpecific”);
24 mockObject.Strict = false;
25
26 var myObject = mockObject.Object as MyAbstractClass;
27 myObject.DoSomethingInteresting();
28
29 MockManager.Verify();
30 }
The down side is that we are forced to use string to mock the method.
Personally I prefer to pay this price than changing the method visibility.
What do you think?
