FakeItEasy throws ExpectationException

Question

I have a problem mocking an interface with an (async) method. The Interface looks like this:

public interface IDataAccessLayer
    {
        Task<bool> ExistsUserAsync(string username, CancellationToken cancellationToken);

        Task<IUser> CreateUserAsync(string username, string password, DateTime dateOfBirth, CancellationToken cancellationToken);
    }

.. the cancellationToken parameter up there is always created and passed in from the outside during runtime (via NancyFx), and when mocking the calls inside a test method like this:

    var validSignupRequest = new UserSignupRequest()
    {
        Username = "meh-spacey_space",
        DateOfBirth = DateTime.Now.Subtract(TimeSpan.FromDays(365*35)),
        Password = "someproper_passw*rd"
    };

    var testDataAccessLayer = A.Fake<IDataAccessLayer>(options => options.Strict());

    var fakeUserInstance = A.Fake<IUser>();

    A.CallTo(() => fakeUserInstance.Username).Returns(validSignupRequest.Username);
    A.CallTo(() => testDataAccessLayer.ExistsUserAsync(validSignupRequest.Username, CancellationToken.None)).Returns(false); // works
    A.CallTo(() => testDataAccessLayer.CreateUserAsync(validSignupRequest.Username, validSignupRequest.Password, validSignupRequest.DateOfBirth, CancellationToken.None)).Returns(fakeUserInstance); // does not work / throws ExpectationException

.. the mocked call to .ExistsUserAsync(...) does work, the .CreateUserAsync one does not work / throws an ExpectationException.

I've checked the underlying code that is being tested and the call is being made using the same values to the .CreateUserAsync(...) method are used & I suspected the dateOfBirth being the culprit, but at least .Ticks wise it is exactly the same.

I am a bit uncertain as to how FakeItEasy performs the signature / parameter value matching because in theory that call IS mocked, but FakeItEasy says it is not. So far it is winning..

Does anyone know what's wrong in my method mocking call(s) up there?

Answer 1

In order to have an "answer" to this question so newcomers don't have to run through the comments and gists and whatnot to figure things out, here's my understanding of what happened:

In the original question, the call

A.CallTo(() => testDataAccessLayer.CreateUserAsync(
                         validSignupRequest.Username,
                         validSignupRequest.Password,
                         validSignupRequest.DateOfBirth,
                         CancellationToken.None))
               .Returns(fakeUserInstance); 

doesn't throw, but later on when the production code was exercised and testDataAccessLayer was called, the configured method was not executed—FakeItEasy didn't think the call matched what was configured.

This is because between setting up the call and the actual call, the DateOfBirth ended up being serialized and deserialized by Jil, as shown in this gist, and the DateTime loses precision, so the parameter is no longer the same. Thus, FakeItEasy sees no need to intercept the call.

As Jörg B. mentions in the comments, there was no problem with FakeItEasy. It was doing the best it could with the data that it was given.

Answer 2

This is just a guess, since I'm unfamiliar with FakeItEasy, but perhaps you need to await the results of the async calls.

A.CallTo(async () => await testDataAccessLayer.CreateUserAsync(   // await the result
                     validSignupRequest.Username, validSignupRequest.Password, validSignupRequest.DateOfBirth, CancellationToken.None))
    .Returns(fakeUserInstance);

Or, depending on how FakeItEasy works internally, it might be in how you check the result:

A.CallTo(() => testDataAccessLayer.CreateUserAsync(
               validSignupRequest.Username, validSignupRequest.Password, validSignupRequest.DateOfBirth, CancellationToken.None))
    .Returns(Task.FromResult(fakeUserInstance)); // test a task, not a real object

A quick search found this page, which leans towards the second solution, but I think either will probably work.