FakeItEasy Cheat Sheet for Moq Users

I am currently learning the ins and outs of the FakeItEasy mocking framework. I know my way around Moq, a simple and easy to use framework for the same purpose. This cheat sheet has examples for the most common use cases and explains the differences to Moq.

 

Why use a mocking framework?

A mocking framework like Moq or FakeItEasy helps you to write unit tests faster. Instead of writing your own classes as stand-ins for your dependencies, you let the framework generate those mocks for you. This is especially helpful when you use dependency injection and want to test your class without the need for a database or web service.

 

Where to start?

Check the Quickstart for your first steps with FakeItEasy. One single page has all you need to start and you are already in the well-written documentation that answers your other questions.

Open your test project, right-click on References and select “Manage NuGet Packages…” to open the NuGet packages dialog. Search for FakeItEasy and install this package:

Alternatively, open the Package Manager Console and type

Install-Package FakeItEasy

 
The following examples use this interface and the minimalistic Job class:

 

No configuration required

To use FakeItEasy you just need to create a fake. As with Moq, you don’t need any configuration to get the default values of a value type back:

The biggest difference to Moq is the handling of reference types. If you do not specify a value, then Moq returns NULL.
The behaviour of FakeItEasy is more user friendly: Whenever possible it creates a fake a dummy. That can be an empty string like in the call for CurrentUser() or a proxy as with CurrentJob(). It only returns NULL when the type can’t be overridden, or it isn’t possible to create all the dummies for a non-default constructor. (For a more precise definition check the explanation by Blair Conrad in the comments section.)

 

Specify a return value

You only need to configure your mock when you need a specific return value for a method call. FakeItEasy has a powerful fluent interface that makes the configuration easy to read:

You can use the same syntax from the configuration to verify that a method call occurred. That makes the memorisation a lot simpler than with Moq. Dedicated methods cover the most common verifications and should this not be enough, you can use MustHaveHappenedANumberOfTimesMatching() to set your own number of calls you expect.

 

Change return values between calls

When you need to mimic a more complex system that changes its state between calls, you can simply keep appending your configuration with those changed values:

Moq offers the same functionality with SetupSequence(), but in a less readable way for scenarios like the one above.

 

Get the argument of a method call

In some test scenarios is changing the return value not enough. FakeItEasy allows you to replace the method with your own code. With full access to the arguments used for the method call, you could catch them and check that the right things happen inside your system:

(In a realistic scenario the call to the Add() method would be inside your system under test.)

In Moq you can use Callback() method to get the same result.

 

Conclusion

FakeItEasy is an easy to use framework. As soon as you get used to the syntax you can work without any problems or surprises. I like the behaviour with reference values even more than in Moq. I don’t change all my test code from Moq to FakeItEasy, but for new projects I will need to consider which mocking framework I should use.

 
Update on 18.2.2018: Use dummy instead of fake as the default behaviour with reference types

2 thoughts on “FakeItEasy Cheat Sheet for Moq Users”

  1. A nice cheat sheet/introduction to FakeItEasy.
    I particularly enjoyed seeing the new call count assertion syntax (such as MustHaveHappenedOnceExactly), as it’s so new I didn’t think anyone even realized it was there yet.

    I’d like to make one correction/suggestion, though. About default return values, you said “Whenever possible it creates a fake. That can be an empty string like in the call for CurrentUser() or a proxy as with CurrentJob(). It only returns NULL when the type can’t be overridden or doesn’t have a default constructor.”

    This is mostly accurate, but the truth is even a little better. We actually try to return a Dummy (see https://fakeiteasy.readthedocs.io/en/stable/default-fake-behavior/#overrideable-members-are-faked and https://fakeiteasy.readthedocs.io/en/stable/dummies/), which will sometimes be a Fake, but doesn’t need to be (for example, “” isn’t a Fake). And we try to make Dummies using even non-default constructors, so long as we can make all the constructor arguments that are required.

    It’s a minor point that probably won’t make any difference to people most of the time. Truth be told, I was surprised you went as deeply into the explanation of default return values and where they come from as you did.

    Thanks!

    Reply
    • Hi,
      Thanks for your kind words and the explanation on how FakeItEasy used dummies. I included a link to that section and will use dummies a bit more in my tests.

      Regards,
      Johnny

      Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.