Are You Mocking Me?!

What Do You Mean by "Mock"?

I want to seriously focus on a type of unit-test technique, one that is so misused, that I would even go so far as to call it an anti-technique. This is the use of Mock Objects.

Mock objects and functions can fill in an important gap when a unit-test is attempting to eliminate dependencies or to avoid the use of an expensive resource. Many mock libraries make it pretty damn simple to mock the behavior of your codes dependencies. This is especially true when the library is integrated into your development environment and will generate much of the code for you.

There are other approaches that exist, which I believe are a better first choice. Whatever method you ultimately chose should depend on the goal of your testing. I would like to ruminate on some of my experiences with Mock Objects as well as provide some alternate possibilities for clipping dependencies for unit tests.

Unit Testing

Mock Objects are only a small element of the larger topic of unit-testing. Therefore, I think it's prudent to provide a brief overview of unit testing to try to set the context of this discussion, as well as align our understanding. Unit testing is a small isolated test written by the programmer of a code unit, which I will universally refer to as a system.

You can find a detailed explanation of what a unit test is and how it provides value in this entry: The Purpose of a Unit Test[^].

It is very important to try to isolate your System Under Test (SUT) from as many dependencies as possible. This will help you differentiate between problems that are caused by your code and those caused by its dependencies. In the book xUnit Patterns, Gerrard Meszaros, introduces the concept of a Test Double used to stand-in for these dependencies. I have seen many different names used to describe test doubles, such as dummy, fake, mock, and stub. I think that it is important to clarify some vocabulary before we continue.

The best definitions that I have found and use today come from this excellent blog entry by, Martin Fowler, Mocks Aren't Stubs. Martin defines a set of terms that I will use to differentiate the individual types of test doubles.

• 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).
• 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'.
• Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

Martin's blog entry above is also an excellent source for learning a deeper understanding between the two general types of testing that I will talk about next.

So A Mock Is Just A Different Type of Test Double?!

No, not really.

Besides replacing a dependency, mock objects add assertions to their implementation. This allows a test to report if a function was called, if a set of functions were called in order, or even if a function was called that should not have been called. Compare this to simple fake objects, and now fake objects look like cheap knock-offs (as opposed to high-end knock-offs). The result becomes a form of behavioral verification with the addition of these assertions.

Mock objects can be a very valuable tool for use with software unit tests. Many unit test frameworks now also include or support some form of mocking framework as well. These frameworks simplify the creation of mock objects for your unit tests. A few frameworks that I am aware of are easyMock and jMock for JAVA, nMock with .NET and GoogleMock if you use GoogleTest to verify C++ code.

Behavior Verification

Mock objects verify the behavior of software. For a particular test, you may expect your object to be called twice and you can specify the values that are returned for each call. Expectations can be set within the description of your mock declaration, and if those expectations are violated, the mock will trigger an error with the framework. The expected behavior is specified directly in the definition of the mock object. This in turn will most likely dictate how the actual system must be implemented in order to pass the test. Here is a simple example in which a member function of an object registers the object for a series of callbacks:

// No, I'm not a Singleton.  
// I'm an Emporium, so quit asking. 
class CallbackEmporium 
{ 
  // Provides functions to register callbacks 
} 
  
TheCallbackEmporium& TheEmporium() 
{ ... } 

// Target SUT 
void Object::Register() 
{ 
  TheEmporium().SetCallbackTypeA( Object::StaticCallA, this ); 
  TheEmporium().SetCallbackTypeB( Object::StaticCallB, this ); 
} 

Clearly the only way to validate in this function is through verifying its behavior. There is no return value, so that cannot be verified. Therefore, a mock object will be required to verify the register function. With the syntax of a Mock framework, this will be a snap, because we add the assertion right in the declaration of the Mock for the test, and that's it!

Data Verification

Ultimately, the function object::Register() is interested to know if the two proper callbacks were registered with TheEmporium. So if you nodded your head in agreement in the previous section when I said "Clearly the only way...", I suggest you stop after you read sentences that read like that and challenge the author's statement. Most certainly, there are other ways to verify, and here is one of them.

1 point if you paused after that trick sentence, 2 points if you are reserving judgment for evidence to back up my statement.

It would still be best if we have a stand-in object to replace TheEmporium. However, If there is some way for use to verify after the SUT call, that the expected callback functions were registered in the correct parameters of TheEmporium, then we do not need a mock object. We have verified the final data of the system was as expected, not that the program executed to a prescribed behavior.

Why Does It Matter?

Tight Coupling between the test and the implementation.

Suppose you wrote your mock object to verify the code in this way:

// This is a mocked yet serious syntax  
// for a mock-object statement to verify Register(). 
Mocker.call( SetCallbackTypeA() 
               .with(Object::StaticCallA)).and() 
      .call( SetCallbackTypeB() 
               .with(Object::StaticCallB)); 

That will test the function as-is currently implemented. However, if the implementation of Object::Register were implemented like anyone of these, the test may report a failure, even though the intended and correct results were achieved by the SUT.

void Object::Register() 
{ 
  TheEmporium().SetCallbackTypeB( Object::StaticCallB, this ); 
  TheEmporium().SetCallbackTypeA( Object::StaticCallA, this ); 
} 

// Too many calls to one of the functions 
void Object::Register() 
{ 
  TheEmporium().SetCallbackTypeA( Object::StaticCallA, this ); 
  TheEmporium().SetCallbackTypeB( Object::StaticCallB, this ); 
  TheEmporium().SetCallbackTypeB( Object::StaticCallB, this ); 
} 

// Call each function twice: 
// Assign incorrect values first. 
// Then call a second time with the correct values. 
void Object::Register() 
{ 
  TheEmporium().SetCallbackTypeA( Object::StaticCallB, this ); 
  TheEmporium().SetCallbackTypeA( Object::StaticCallA, this ); 
  TheEmporium().SetCallbackTypeB( Object::StaticCallA, this ); 
  TheEmporium().SetCallbackTypeB( Object::StaticCallB, this ); 
} 

// Assign incorrect values first. 
// Then call a second time with the correct values.void Object::Register() 
{ 
  TheEmporium().SetCallbackTypeA( Object::StaticCallB, this ); 
  TheEmporium().SetCallbackTypeB( Object::StaticCallA, this ); 
  TheEmporium().SetCallbackTypeA( Object::StaticCallA, this ); 
  TheEmporium().SetCallbackTypeB( Object::StaticCallB, this ); 
} 

All four of these implementations would have continued to remain valid for the data validation form of the test. Because the correct results were assigned to the proper values at the return of the SUT.

When the Mock Object Patronizes You

Irony. Don't you love it?!

Mock objects can get you very far successfully. In fact, you may get towards the very end of your development phase and you have unit tests around every object and function. You are wrapping up your component integration phase. Things are not working as expected. These are some that I have personally observed:

• The compiler complains about a missing definition
• The linker (for the C and C++ folks) complains about undefined symbols have been referenced
• This is a network application, everything compiles and links, the program loads and doesn't crash. It doesn't do anything else either. You connect a debugger, it is not sending traffic.

I have seen developers become so enthusiastic with how simple mock objects made developing tests for them, that they virtually created an entire mock implementation. When it compiled and was executed, critical core components had a minimal or empty implementation. All of the critical logic was complete and verified. However, the glue that binds the application together, the utility classes, had not been implemented. They remained stubs.

Summary

There are many ways to solve problems. Each type of solution provides value in its own way. Some are simple, others elegant, while others sit and spin in a tight loop to use up extra processing cycles because the program doesn't work properly on faster CPUs. Just be aware of what value you are gaining from the approaches that you take towards your solution. If it's the only way you know, that is a good first step. Remember to keep looking, because their may be better solutions in some way that you value more.

To know and not do, is to not yet know.