Mock trainwreck

If someone wanted to write a test looking for a library that receives public funding, or by its head librarian, he or she might use code like the following:

Java

assertEqual(
    l.getHeadLibrarian()
        .getName().split(" ")[1]
    , "Smith")
assertEqual( 
    l.getFunding().getType()
    , "public")

Ruby

l.headLibrarian.name.split(/ +/).last.should == "Smith"
l.funding.type.should == "public"

To mock up an object that matches the search result, they would have to have mocking code like what follows:

Java

HeadLibrarian h = mock(HeadLibrarian.class);
when(h.getName()).thenReturn("Jane Smith");

Funding f = mock(Funding.class);
when(f.getType()).thenReturn("public");

Library l = mock(Library.class);
when(l.getHeadLibrarian()).thenReturn(h);
when(l.getFunding()).thenReturn(f);

Ruby

h = mock('HeadLibrarian', :name => 'Jane Smith')
f = mock('Funding', :type => 'public')
l = mock('Library', :HeadLibrarian => h, :Funding => f)

This is an example of a mock trainwreck, because it is a mock up of two unrelated objects, but it relies on a class, Library, to point to them both.^[5]

A mock trainwreck can be avoided by making general code changes or by more specific changes through the use of dependency injection and libraries. General code changes allow a nested model to be made more simple, primarily though the creation of an assessor to access the sub property. This prevents the deep nesting which causes the mock trainwreck, and this assessor can be mocked easily.

Dependency injection (DI), the process by which a dependency is passed to the client which will use it, can be used to soften the trainwreck. One method of DI that is easy to use is a location object to reduce the complexity of building the mock object. Below is the example above reworked with a DI build_mock method to help set mock values on dependent objects. While for this simple example it doesn't appear to help much, in a more complicated scenario it could reduce complexity in manually setting the values.^[6]

def build_mock(name, map, locator, refs)
  obj =  mock(name, map)
  refs.each do |ref|
    obj.send("#{ref}=", locator[ref.to_sym])
  end
  obj
end

locator = {}
locator[:HeadLibrarian] = mock('HeadLibrarian', :name => 'Jane Smith')
locator[:Funding] = mock('Funding', :type => 'public')
locator[:Library] = build_mock('Library', {}, locator, ['HeadLibrarian', 'Funding'])

Testing library in various languages can make the mock trainwreck easier to navigate with helpers. An example is Mockito that provides annotations to assist in injecting mocks into objects. Using the @InjectMocks annotation and @Mock annotation, when Mockito initializes all the mocks it will inject Library with the mocks for funding and head librarian.^[7]

public class LibraryTester {
    @Mock HeadLibrarian h;
    @Mock Funding f;
    @InjectMocks Library l;
    
    @Before public void initMocks() {
        MockitoAnnotations.initMocks(this);        
    }
    
    @Test public void testLibrary() {
        when(l.getHeadLibrarian().getName()).thenReturn("Jane Smith");
        when(l.getFunding().getType()).thenReturn("public");
        
        //tests here
    }
}

The use of libraries can also be used to address mock trainwreck. One such library is called demeter, and it can be used to provide Law of Demeter duck typing assessors that automatically creates assessors for single level nested models. By using this library, a person can mock the assessors that their code uses of the child function, as seen in the example below.^[8]

require "demeter"

class Library
  extend Demeter

  demeter :HeadLibrarian
  demeter :Funding

  def initialize
    @HeadLibrarian = HeadLibrarian.new
    @Funding = Funding.new
  end
end

l = mock('Library', :HeadLibrarian_name => 'Jane Smith', :Funding.type => 'public')
l.HeadLibrarian_name #Jane Smith