My last blog was the third in a series of blogs on approaches to testing code and discussing what you do and don’t have to test. It’s based around my simple scenario of retrieving an address from a database using a very common pattern:

...and I proffered the idea that any class that doesn’t contain any logic doesn’t really need unit testing. In this I included my data access object, DAO, preferring instead to integration test this class to ensure it worked in collaboration with the database.

Michael Feather’s book Working Effectively with Legacy Code states that a test is not a unit test if:

It talks to a database.

It communicates across a network.

It touches the file system.

You have to do special things to your environment (such as editing configuration files) to run it.

To uphold these rules, you need to isolate your object under test from the rest of your system, and that’s where stub objects come in. Stub objects are objects that are injected into your object and are used to replace real objects in test situations. Martin Fowler defines stubs, in his essay
Mocks Aren’t Stubs as:

“Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'”.

Picking a word to describe stubs is very difficult, I could choose
dummy or
fake, but there are types of replacement object that are known as dummies or fakes - also described by Martin Fowler:

Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.

Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).

However, I have seen other definitions of the term
fake object,for example Roy Osherove in is book
The Art Of Unit Testing defines a fakes object as:

A fake is a generic term that can be used to describe either a stub or a mock object...because the both look like the real object.

...so I, like many others, tend to call all replacement objects either
mocks or
stubs as there is a difference between the two, but more on that later.

In testing the AddressService, we need to replace the real data access object with a stub data access object and in this case, it looks something like this:

Note the simplicity of the stub code. It should be easily readable, maintainable and NOT contain any logic and need a unit test of its own. Once the stub code has been written, next follows the unit test:

Note that in writing a unit test, we’re aiming for clarity. A mistake often made is to regard test code as inferior to production code with the result that it’s often messier and more illegible. Roy Osherove in
The Art of Unit Testing puts forward the idea that test code should be more readable that production code. Clear tests should follow these basic, linear steps:

Create the object under test. In the code above this is done in the setUp() method as I’m using the same object under test for all (one) tests.

Setup the test. This is done in the test method testFindAddressWithStub() as the data used in a test is specific to that test.

Run the Test

Tear down the test. This ensures that tests are isolated from each other and can be run IN ANY ORDER.

Using a simplistic stub yields the two benefits of isolating the AddressService from the outside world and tests that run quickly.

How brittle is this kind of test? If your requirements change then the test and the stub changes - not so brittle after all?