Calls are recorded after applying the best rule, not when received

From StackOverflow question FakeItEasy assert that method call to method.

@baruchiro had a test that passed in 2.2.0 and failed in 5.1.0:

public class Foo
{
    public virtual void MethodA()
    {
        MethodB();
    }

    public virtual void MethodB() { }
}

…

var foo_fake = A.Fake<Foo>(options => options.CallsBaseMethods());

foo_fake.MethodA();

A.CallTo(() => foo_fake.MethodA()).MustHaveHappened()
    .Then(A.CallTo(() => foo_fake.MethodB()).MustHaveHappened());

The failure indicated that both calls happened, but in the wrong order.

We inadvertently changed the behaviour in #1124, released in 3.4.2, when we started recording the call in the FakeManager after applying the best-matching rule, rather than in the CastleInvocationCallAdapter.

We could record the call before looking for the best rule to apply. I think this is a good fix anyhow, as it more accurately reflects when the call was made, irrespective of any time FakeItEasy takes to figure out what to do with it.

[blairconrad]

@nkosihenry, thanks. I see your point about the wording and the semantics. Sadly, to some degree, this is in the eye of the reader.

To me, “A call to blah must have happened” talks more about when the call happened. I’m quick to say “no” to features, but I don’t really see much benefit in differentiating between when a call is begun and when it finishes, especially when the goings-on between the two events should all be FakeItEasy or user-supplied test code. In the interest of keeping the API small, I think we should supply only the one check, and I think MustHaveHappened adequately conveys the intent (also requires no rework for the vast majority of users for whom we’re talking about a too-fine distinction).

[blairconrad]

This change has been released as part of FakeItEasy 5.1.1.