Getting Test Doubles in Place

You have two jobs when introducing a test double. First, code the test double. Second, get the target to use an instance of it. Certain techniques for doing so are known as dependency injection (DI).

In the PlaceDescriptionService example, we injected the test double via a constructor. In some circumstances, you might find it more appropriate to pass the test double using a setter member function. These ways to inject a test double are known as (surprise!) constructor injection or setter injection.

Other techniques for getting test doubles in place exist. Use the one that’s most appropriate for your circumstance.

Override Factory Method and Override Getter

To apply Override Factory Method, you must change the production code to use a factory method any time a collaborator instance is needed. Here’s one way to implement the change in the PlaceDescriptionService:

Instead of referring to the member variable http_ for interactions with the HTTP service, the code now calls the protected member function httpService to obtain an Http pointer.

In the test, we define a derivative of PlaceDescriptionService. The primary job of this subclass is to override the factory method (httpService) that returns an Http instance.

We change our tests to create an HttpStub shared pointer and store it in the PlaceDescriptionService_StubHttpService instance. Here’s what MakesHttpRequestToObtainAddress now looks like:

Override Factory Method demonstrates the hole in coverage created by using test doubles. Since our test overrides the production implementation of httpService, code in that method never gets exercised by the tests. As stated before, make sure you have an integration test that requires use of the real service! Also, don’t let any real logic sneak into the factory method; otherwise, you’ll grow the amount of untested code. The factory method should return only an instance of the collaborator type.

As an alternative to Override Factory Method, you can use Override Getter. With respect to our example, the difference is that the httpServer function is a simple getter that returns a member variable referencing an existing instance, whereas in Override Factory, httpServer is responsible for constructing the instance. The test remains the same.

Used sparingly, Override Factory Method and Override Getter are simple and effective, particularly in legacy code situations (see Chapter 8, ​Legacy Challenges​). Prefer constructor or setter injection, however.

Introduce via Factory

A factory class is responsible for creating and returning instances. If you have an HttpFactory, you can have your tests tell it to return an HttpStub instance instead of an Http (production) instance. If you don’t already have a legitimate use for a factory, don’t use this technique. Introducing a factory only to support testing is a poor choice.

Here’s our factory implementation:

During setup, the test creates a factory and injects an HttpStub instance into it. Subsequent requests to get on the factory return this test double.

We change the production code in summaryDescription to obtain its Http instance from the factory.

Since we’re passing the factory through the constructor, this pattern is little different from constructor injection, except that we now have an extra layer of indirection.

Introduce via Template Parameter

Some of the injection techniques can be somewhat clever. Injecting via a template parameter is another option that doesn’t require clients to pass a collaborator instance. Its use is best constrained to legacy situations where a template already exists.

We declare the PlaceDescriptionService class as a template that can be bound to a single typename, HTTP. We add a member variable, http_, of the parameter type HTTP. Since we want clients to use the class name PlaceDescriptionService, we rename the template class to PlaceDescriptionServiceTemplate. After the template definition, we supply a typedef that defines the type PlaceDescriptionService as PlaceDescriptionServiceTemplate bound to the production class Http. Here’s the code:

In the test fixture, we declare the service to be of type PlaceDescriptionServiceTemplate bound to the mock type, HttpStub:

The test doesn’t provide PlaceDescriptionService with an instance of the mock; it supplies the mock’s type. PlaceDescriptionService creates its own instance of this type (as the member variable http_). Since Google Mock will be looking to verify interaction expectations on the template object’s instance, we need to provide the test with access to it. We change the test to obtain the stub instance via an accessor function on PlaceDescriptionServiceTemplate named http.

You can support introducing a mock via a template parameter in a number of ways, some even more clever than this implementation (which is based on the Template Redefinition pattern in Working Effectively with Legacy Code [Fea04]).

Injection Tools

Tools to handle injecting collaborators as dependent objects are known as dependency injection (DI) tools. Two known C++ examples are Autumn Framework^[26] and Qt IoC Container.^[27] Michael Feathers weighs in on the state of DI frameworks in C++: “It seems that to do DI in C++, you have to place constraints on the classes you create...you have to make them inherit from some other class, use macro preregistration or a metaobject library.”^[28] You should first master the manual injection techniques described here and then investigate the tools to see whether they improve things. DI tools are generally much more effective in languages that support full reflective capabilities.