Wednesday, April 04, 2007

TotT: Stubs Speed up Your Unit Tests

Michael Feathers defines the qualities of a good unit test as: “they run fast, they help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc.

By substituting custom objects for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code.

A variety of different terms are used to refer to these “custom objects”. In an effort to clarify the vocabulary, Gerard Meszaros provides the following definitions:

  • Test Double is a generic term for any test object that replaces a production object.
  • Dummy objects are passed around but not actually used. They are usually fillers for parameter lists.
  • Fakes have working implementations, but take some shortcut (e.g., InMemoryDatabase).
  • Stubs provide canned answers to calls made during a test.
  • Mocks have expectations which form a specification of the calls they do and do not receive.

For example, to test a simple method like getIdPrefix() in the IdGetter class:

public class IdGetter { // Constructor omitted.
public String getIdPrefix() {
try {
String s = db.selectString("select id from foo");
return s.substring(0, 5);
} catch (SQLException e) { return ""; }

You could write:

db.execute("create table foo (id varchar(40))"); // db created in setUp().
db.execute("insert into foo (id) values ('hello world!')");
IdGetter getter = new IdGetter(db);
assertEquals("hello", getter.getIdPrefix());

The test above works but takes a relatively long time to run (network access), can be unreliable (db machine might be down), and makes it hard to test for errors. You can avoid these pitfalls by using stubs:

public class StubDbThatReturnsId extends Database {
public String selectString(String query) { return "hello world"; }
public class StubDbThatFails extends Database {
public String selectString(String query) throws SQLException {
throw new SQLException("Fake DB failure");
public void testReturnsFirstFiveCharsOfId() throws Exception {
IdGetter getter = new IdGetter(new StubDbThatReturnsId());
assertEquals("hello", getter.getIdPrefix());
public void testReturnsEmptyStringIfIdNotFound() throws Exception {
IdGetter getter = new IdGetter(new StubDbThatFails());
assertEquals("", getter.getIdPrefix());

Remember to download this episode of Testing on the Toilet and post it in your office.


  1. Although I am a big fan of these patterns you can run into problems with this stuff:
    Lots of unit tests with mocks etc on a dao layer can turn an agile code base into a paralysed code base; on a simple db change you can't just fix abstractions you have to re-work tests.
    If an application is heavily data driven the value of the tests is dependent on the quality of your faked data; which is too onerous to maintain.
    Mocking another system is clearly beneficial but mocking out a layer (which the db can be regarded as) is a lot of high cost effort.
    I guess you have to be pragmatic; consider: testing with a cut down database, having a fast unit test run and a slower integration test run, removing test code that hampers agility.

  2. Martyn is dead-on. Choices like these have trade-offs to consider. One good test quality which I have difficulty getting people to understand is "obviousness" - ideally a test should look obviously correct. Mocks and stubs may make your tests less obviously correct (thus more difficult to understand and maintain) because they hide part of the test implementation in the stub rather than in the test itself.

    For example, in the example given above, the test stub has hardcoded:

    return "hello world"

    Then further down later in the test is:

    IdGetter getter = new IdGetter(new StubDbThatReturnsId());
    assertEquals("hello", getter.getIdPrefix());

    The test itself is not "obviously" correct without studying the stub. Really, you want the test to be as obviously correct as possible within the test itself. In this case, "obviousness" can be increased with a simple change (the corresponding change to the stub is left as an exercise for the reader):

    IdGetter getter = new IdGetter(new StubDbThatReturnsId("hello world"));
    assertEquals("hello", getter.getIdPrefix());

    However, its not always that easy to improve "obviousness" when you're using stubs, especially if you have a lot of them or are reusing stubs across tests and packages.

  3. bert, you're right that sometimes these tests are less obvious. One thing I'd consider is using some sort of mocking framework to create the doubles - they take a small amount of time to learn, but provide much more powerful testing abilities than can easily be had be hand-coding the doubles. The return is well worth the effort expended.

    For example:
    DynamicMock db = new DynamicMock(typeof Database);
    db.ExpectAndReturn("selectString", "hello world");
    IdGetter getter = new IdGetter((Database)db.Object);
    assertEquals("hello", getter.getIdPrefix());

    This way the obviousness is preserved, and the pattern is similar between tests; having a stub throw an exception is just a matter of calling ExpectAndThrow instead of coding up a whole new class.

  4. Ruby's Rspec makes this kind of thing really elegant and readable. I'd post some example text here, but it looks like it'll just get mangled.

    Check it some examples here:

  5. "If an application is heavily data driven the value of the tests is dependent on the quality of your faked data; which is too onerous to maintain."

    That is a problem with state based testing, not caused by mocks/stubs. The whole point of mocks/stubs is to get away from testing state and start testing behavior and interactions.

    Essential reading is "Mock Roles Not Objects":


The comments you read and contribute here belong only to the person who posted them. We reserve the right to remove off-topic comments.