bypass dispose for testing

Question

Hi I'm trying to test a method. I want to ensrur that there is a method call in that method (calling service) the code look like this:

using(proxy = new Proxy())
{ 
      proxy.CallService();
}

I swap the proxy with fake object (using TypeMock) but get error because of the fake object disposed in the end of block. I don't want to remove that "using" block. Thanks

Answer 1

Make the mock object expect to be disposed too. (I don't know TypeMock, but in some other mocking frameworks this would just be a case of calling Dispose yourself during the "record" phase.) In fact, I'd say that without that the test is wrong anyway, because presumably you want to be certain that the proxy is being disposed.

Answer 2

Just instruct your mock of Proxy to expect a call to Dispose() as well. If you're using reflective mocks you need to do something like this

var proxyMock = MockManager.Mock(typeof(Proxy));
// set up regular calls to proxy, e.g.
proxyMock.ExpectCall("CallService");
proxyMock.ExpectCall("Dispose");

for natural mocks place a call to Dispose() in your using block.

Answer 3

Make the fake object implement IDisposable:

class FakeObject : IDisposable
{
    public void Dispose() {}
}

Answer 4

Disclaimer: I work at Typemock
If you are using the Arrange Act Assert API you can use Members.ReturnRecursiveFakes when you are creating your fake object (Note: this is the default from version 5.2.0) This will automatically fake the Dispose method as well.

so your test will be something like this:

var fake = Isolate.Fake.Instance<Proxy>(Members.ReturnRecursiveFakes);
Isolate.WhenCalled(() => fake.CallService()).IgnoreCall();
Isolate.Swap.NextInstance<Proxy>().With(fake);

UnderTest classUnderTest = new ClassUnderTest();
classUnderTest.MethodUnderTest(); // assuming the Proxy instance is used here.

Isolate.Verify.WasCalledWithAnyArguments(()=>fake.CallService());

I want to add to what Jon Skeet said that I would create a separate test that will ensure that the Dispose method is called.
I think it is a good practice to assert one thing in each test method, that way when a test breaks up you'll know the reason immediately.