Mutli Mocks and verifying behavior

I have the following piece of code:

protected override void DoClose()
{
    IDisposable dispoable = enumerator as IDisposable;
    if (dispoable != null)
        dispoable.Dispose();

    dispoable = enumerable as IDisposable;
    if(dispoable != null)
        dispoable.Dispose();
}

How do I verify that it correctly disposes both enumerator and enumerable when the method is called?

Here is the test that I wrote, it is using Rhino Mocks' Multi Mocks feature to generate a proxy that has more than a single implementation.

[Test]
public void WillDisposeInternalEnumeratorAndEnumerableWhenDisposed()
{
    MockRepository mocks = new MockRepository();
    IEnumerable<Row> enumerable = mocks.DynamicMultiMock<IEnumerable<Row>>(typeof(IDisposable));
    IEnumerator<Row> enumerator = mocks.DynamicMock<IEnumerator<Row>>();
    using(mocks.Record())
    {
        SetupResult.For(enumerable.GetEnumerator()).Return(enumerator);
        enumerator.Dispose();
        ((IDisposable)enumerable).Dispose();
    }
    using (mocks.Playback())
    {
        DictionaryEnumeratorDataReader reader =
            new DictionaryEnumeratorDataReader(new Dictionary<string, Type>(), enumerable);
        reader.Dispose();
    }
}

Simple, and to the point.

Print | posted on Saturday, January 05, 2008 6:21 PM

Feedback


Gravatar

# re: Mutli Mocks and verifying behavior 1/5/2008 8:34 PM Rinat Abdullin

Sometimes I wish my IDE had spell-check support.

You've got a typo in there: "dispoable"


Gravatar

# re: Mutli Mocks and verifying behavior 1/6/2008 1:25 PM Luke Breuer

I'm confused. Your testing code has many more characters and lines than the code being tested. It seems that there is more possibility for the testing code to have errors than the tested code. This contributes to my hesitance, yes hesitance, to go full-tilt with unit testing. Please assuage my worries, Oren. :-)


Gravatar

# re: Mutli Mocks and verifying behavior 1/6/2008 8:41 PM Ayende Rahien

Luke,
This is normal. In this tiny sample, you probably see it blown up, but in test driven code, the test / code ration is usually in favor of the tests

Comments have been closed on this topic.