Mocking method chains part 1: When not to. Coupling, encapsulation, redundancy and the Law of Demeter.

Today I'd like to start discussing mocking of sequences of method call chains. This discussion will be split in two parts, part two coming soon.

The basics of call chains

When I say "call chain", I mean something like this:

a.X().Y().Z().V();

So basically we're just invoking methods on a result of another method. This is a construct that probably everyone programming in an object oriented language have come across, so I'll only note that I don't mean "call chain" merely as a synonym of invoking method on returned object (because it would be plain silly to make up a name for something that obvious), but rather the style of invoking methods "in a chain" as seen in the example above.

Call chains may be a design smell

Now, one thing I want to make clear is that there's a point in mocking method chains only in specific situations. This is because call chains can be either a design smell or a sophisticated API design technique. Today, I'm gonna talk a little bit about the first case, leaving the latter for part two.

Let's take a look at the following example of call chain being just a design smell (we're gonna discuss why in a minute):

bool wasWrittenInAmericanEnglish = message
  .GetWrappedFrame()
  .GetHeader()
  .GetLocale() == "en-US";

So, what's really wrong with this? I can guess that you've probably seen code like this many times before. The issue with the example above is that we're now coupled to all of the types of objects between the message object and the locale string. Also, we're coupled to the information that message language can be obtained by locale, as well as to the name of the en-US locale and so on.

Moreover, we're coupled to if and when will subsequent calls return valid objects. Let's say that there are some messages that do not contain a header and we can't obtain a locale information. We decide that we want to use application's default locale in such case - this decision will have to be properly handled by this code. If this isn't the only place where we need to follow this default locale policy, we've already introduced redundancy (oh, and did I say that we've violated encapsulation by failing to protect the information on how the locale is obtained?). Another example might be adding support for messages without locale specified in the header.

Here's how ugly may this kind of code turn when only these two constrains are loosened:

const string EnUs = "en-US";
bool wasWrittenInAmericanEnglish 
  = EnUs == getCurrentAppLocale();

var wrappedFrame = message.GetWrappedFrame();

if(wrappedFrame.HasHeader())
{
  var header = message.GetHeader();
  var locale = header.GetLocale();
  if(locale != null)
  {
    wasWrittenInAmericanEnglish = locale == EnUs;
  }
}

See how the code was impacted by broken encapsulation? By the way, this is also a violation of Law of Demeter.

As a side note, the issue does not have anything to do with the calls being chained. It may as well look like this without it changing the problem at all:

var frame = message.GetWrappedFrame();
var header = frame.GetHeader();
var locale = header.GetLocale();
var wasWrittenInAmericanEnglish = locale == "en-US";

So the chain in such smelly situations is rather a workaround than an API design technique. The workaround is for typing too much and dealing with too many variables that are only used to obtain other variables.

The diagnosis and the cure

We mainly run into this kind of code in four situations:

1. We introduce it during bottom-up coding (because we have access to all the data wee need, just need to "reach it through the dots")
2. We introduce it when not using TDD, because there is nothing to tell us loud enough that it's wrong
3. We introduce it by abusing mocking frameworks (whose authors usually add support for mocking of method chains, but not with such situations in mind)
4. We encounter it in legacy code

In any case, you don't want to mock the methods chain. I mean, really really, you don't want to mock it. Or specify it.

What you DO want to do is to refactor it into something like this:

bool wasWrittenInAmericanEnglish 
  = message.WasWrittenIn(Languages.AmericanEnglish);

Here, the code is decoupled from all the information about the encapsulated calls - it doesn't know the structure of message object or the locale format used, or even that the check is made by comparing locale values of any sort. We're safe and sound.

Also, it's very straightforward to mock, even with manual mocks. That's one of the reasons some of the TDD gurus suggest to use manual mocks (at least when getting started) - they provide more of the diagnostic pain that points where the design is going wrong.

And how to avoid running into such smelly chains when writing new code? My favorite technique is to use Need Driven Development, at the same time forgetting about the call chain mocking feature of some of the mocking frameworks.

Ok, that's it for today, in the next installment, we'll take a look at some proper usage of call chains and three classes of such chains: ordered chains, unordered chains and chains with grammar. Stay tuned!