FakeItEasy assert that method call to method

Question

I have an unit-test written with FakeItEasy v2.2.0.

The test tests that a method, let call it MethodA call to MethodB.

The simple class:

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

    public virtual void MethodB() { }
}

The simple test:

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());

With FakeItEasy 2.2.0, the code passed.

But when we upgrade to 5.1.0, the code throw exception that says:

The calls were found but not in the correct order among the calls

When we say the method is called? At the start of execution, or at the end?

Or, what is the right way to test this case?

Answer 1

Update: this was a bug, and has been fixed. As of FakeItEasy 5.1.1, the behaviour is restored to what it was in 2.2.0

---

We record that a call was made after the call is finished, so in your case, the order would be

• execute methodA
• execute methodB
• record that methodB happened
• record that methodA happened

However, in 3.4.2, we released the fix to Setting ref argument values masks incoming argument values used to verify calls. This moved the point at which we record the call's "sequence number" from within the CastleInvocationCallAdapter to the FakeManager. The former would have recorded methodA's invocation before the call to methodB.

It's a shame this breaks your use case. I consider the new behaviour to be a bug, and created issue #1583 - Calls are recorded after applying the best rule, not when received on GitHub.

Personally, though, I'd look at the test (which I assume is more complicated than you presented here). I'd take @Nikosi's advice and not check the order of the calls. Knowing that they were both called (or even just that methodB was called) might be enough.