On Part I, I described what chains are, and the challenge they pose for Isolator. As you've already gathered, I will use every opportunity to use lame puns, so the word of the day is:
Interpreta-chain
How does Isolator interpret chains?
Well, first let's see how it interprets method calls in general. Isolator uses the profiler API to intercept calls by the CLR. Whenever a method call is invoked, Isolator intercepts it first and does one of the following operations:
- Call the original method
- Record an expectation
- Return a mocked value
Since this is already compiled code, there's no signaling of an end of line. The only information it receives is the next call.
Let's examine this code:
using (RecordExpectations rec = RecorderManager.StartRecording())
{
int x = a.b().c();
rec.Return(5);
}
Isolator receives the calls in this order (the assignment is implicit):
XReturn = a.b() // returns a default "temporary" return value XReturn
int x = XReturn.c() // returns a default "temporary" return value x
rec.Return(5) // substitutes the former x with 5.
Now look at this chain:
int x = a.b().c(d.e(f.g().h(2,i.j()));
Can you guess which 3 method calls are invoked first? If you guessed a.b(), f.g(), and i.j() in this order, you are correct. You are probably also suffering from the same headache I had when trying to dive into chain land. So method calls come in a somewhat confusing order, until you understand the rules.
Identifica-chain
A chain has a head and a tail, which identify it. Knowing when a chain starts is easy - with the first call. But where does it end?
Let's look at this code:
using (RecordExpectations rec = RecorderManager.StartRecording())
{
int x = a.b().c(d.e(f.g().h(2,i.j()));
rec.Return(5);
}
The writer of this code, evil-minded as he is, concentrates on one thing - returning 5 instead of the call to a.b().c(...) method. No expectations are set or examined on the other calls that are on the way, and that starts with a.b(). Rule #1 Isolator uses the Return call to identify the end of the chain, and set the return value on that last expectation.
Now let's look at the following simpler code containing an error:
using (RecordExpectations rec = RecorderManager.StartRecording())
{
x = a.b();
// Missing call to rec.Return(...)
int y = d.e();
rec.Return(5);
}
The writer of this code, expert as he is, forgot to put a Return call following the first call. Isolator continues to receive the calls, and needs to decide if the chain has been broken. Rule #2 to identifying a chain is when the return value of the former call, is the target of this call. In this case, the returned value of a.b() is an instance, while the next call d.e() is static. A static call has no instance and therefore we can identify a chain break.
And, in the former case, the chain break actually points to an error in the code. This helps us give the correct notification to the user.
Rule #2 is also a generalization of the following case:
using (RecordExpectations rec = RecorderManager.StartRecording())
{
a.b();
// No need to return a value, it just returns void
int y = d.e();
rec.Return(5);
}
Since a.b() is a void call, there's no need for rec.Return call. Rule #3 says: if a method returns void, it's a chain breaker.
Next time, I'm going to discuss extension methods, and how they fit in chains.
That's right. Narcisse Adjalla is the winner of the Wii sweepstakes in our last webcast. He's now the proud owner of a new Nintendo Wii. 
