Creating Smart Stubs with a Mock Framework

This article is taken from The Art of Unit Testing from Manning Publications. As part of a chapter on mock object frameworks, this segment shows how to create a stub and fake an exception with a dynamically created stub. For the table of contents, the Author Forum, and other resources, go to http://www.manning.com/osherove/.

It is being reproduced here by permission from Manning Publications. Manning ebooks are sold exclusively through Manning. Visit the book's page for more information.

Softbound print: May 2009 | 320 pages
ISBN: 1933988274

 

Use code "dzone30" to get 30% off any version of this book.

A stub can also be created using mocking frameworks. Semantically speaking, a stub is a simulated object, just like a mock object, that will support our test so that we can test other things. In short, a stub will always make “happy noises” when being called, and can never be used to see if the test passed or not. Calling VerifyAll() will not verify anything against stub objects. Only against mocks. Most mocking frameworks contain the semantic notion of a stub and RhinoMocks is no exception. Listing 1 shows how you create a stub object:

Listing 1: Creating a stub looks remarkably similar to creating a mock object. Only the creation method call changes.

[Test]
public void ReturnResultsFromStub()
{
    MockRepository mocks = new MockRepository();
    IGetRestuls resultGetter = mocks.Stub<IGetRestuls>();

    using(repository.Record())
    {
        resultGetter.GetSomeNumber("a");
        LastCall.Return(1);
    }

    int result = resultGetter.GetSomeNumber("a");
    Assert.AreEqual(1, result);
}

The Syntax looks almost the same as using mock objects But what would happen when running a test that does not call an expected method on the stub, but still verifies expectations as shown in listing 2:

Listing 2: Verifying expectations on a stub object cannot fail a test. That’s what mock objects are for.

public void StubNeverFailsTheTest()
{
    MockRepository mocks = new MockRepository();
    IGetRestuls resultGetter = mocks.Stub<IGetRestuls>();

    using(mocks.Record())
    {
        resultGetter.GetSomeNumber("a"); |#1
        LastCall.Return(1);
    }

    resultGetter.GetSomeNumber("b");
    mocks.VerifyAll(); |#2
}

Annotation #1: Is this really an expectation?
Annotation #2: Will this fail the test?

The test should still pass, because the stub, by definition, is incapable of breaking a test, and that’s also how it behaves in RhinoMocks. Any expectations set on it are purely so we can determine the return value or the exceptions to throw from them.

It’s important to note that RhinoMocks actually contains a very nice feature for simple properties on stub objects. Get-set properties are automatically implemented and can be set and used as if this was a real object, without needing to setup a return value. You can still set up a return value for a property, but you don’t need to do it for each and every property on a stub object as shown in the next piece of code:

ISomeInterfaceWithProperties stub =
mocks.Stub<ISomeInterfaceWithProperties>();
stub.Name = "Itamar";
Assert.AreEqual("Itamar",stub.Name);

Let’s see how we can simulate an exception using expectations. Listing 3 shows an example of how you would simulate an OutOfMemoryException in a test from a stub:

Listing 3: Faking an exception with a dynamically created stub is very easy and very readable when using the LastCall class.

public void StubSimulatingException()
{
    MockRepository mocks = new MockRepository();
    IGetRestuls resultGetter = mocks.Stub<IGetRestuls>();

    using(mocks.Record())
    {
        resultGetter.GetSomeNumber("A");
        LastCall.Throw(
                new OutOfMemoryException("The system is out of memory!")
                );
    }

    resultGetter.GetSomeNumber("A");
}

This test will fail due to a nasty out of memory exception. That’s how easy it is.