I’ve been trying out different isolation frameworks lately and reading about their features and differences. In terms of feature, most constrained isolation frameworks are almost the same. But there are couple of important points about naming and readability that I think worth paying attention to. I’ve used Moq in my previous projects, but recently, I’ve realized that frameworks such as FakeItEasy and NSubstitute are a better choice. So I made a switch to FakeItEasy. In this post I explain my reasons for making that transition.

Moq’s naming is confusing

Naming tests and its constituent parts are important. The reason is that how we name things will shape how we think about them and how we use them as a result. If we take a look at testing nomenclature, we have at least three important terms, Fake, Stub and Mock. It’s accepted that each one of them has different meaning and should be used in different circumstances.

Fake: An object that can be used in place of another object. Fake is a general term that can be used for both stubs and mocks. But fakes can later becomes stub or mock, depend on how we decide to use them.

Stub: An object that get passed to another as dependency which doesn’t have any real implementation. We can change the internal implementation of its parts to return different results so we can test different parts of our app. It only help us in writing tests, it doesn’t do anything else in and of itself and can’t make our test fail. That is it doesn’t assert anything about itself.

Mock: An object that tracks its interaction with other objects and let us test our assumptions about those interactions. In other word it has behavior verification and can pass or fail our test based on its expectations. Mock is less prevalent than stubs, because testing system state changes and return values are preferable to testing internal interactions.

But Moq throws the term Mock all over the place. We always new up a Mock whether we want to use it as a stub or as a mock. Let me clarify what I’ve said with an example.

In the above example the test DetailPassTheCorrectIdIntoPortfolioByIdQuery use a mock called mediator. It’s a mock because later the object is used to verify that correct PortfolioId has sent to its Send method. On the other hand, the test DetailReturnsCorrectView use a stub called mediator. It’s a stub because it only served as a replacement with some tweaked behavior. But as you can see in second example, we still new up a mock, and this can become confusing. Now let’s take a look at FakeItEasy and NSubstitude.

The code above doesn’t use the word mock any place in our code. It’s our usage that determines whether it’s a mock or a stub. The reason that knowing the difference and avoiding confusion is important is that we should have one assert per test, and here mock object makes the assertion for us. So by extension we could say, we should have only one mock object per test. But when it comes to stubs, it acts only as a replacement and we can have many stubs in one unit test.

Moq is not as readable as FakeItEasy and NSubstitude

Unit tests can act as document for our code. It it can show us how a particular piece of code works and how it should behave. If we believe that about unit tests, then it’s reasonable to say things that makes our unit tests less readable is kind of a waste of our efforts. Let’s compare the readability of these frameworks.

In my opinion the readablity of FakeItEasy and NSubstitude is far superior to Moq. NSubtitude syntax is more terse, but I prefer FakeItEasy because the AAA-syntax is more consistent and it still readable.

FakeItEasy and NSubstitude have better documentation and simpler to use

Last point to touch on is documentation and ease of use. NSubstitude documentation is very good. FakeItEasy documentation is good enough, but not as good as NSubstitude. In terms of ease of use I think NSubstitude is the simplest and the syntax is intuitive, FakeItEasy syntax is both intuitive and consistent.

Summary

This post discussed why naming and readability matters in our tests. It also showed what other isolation frameworks has to offer and the value of switching to these frameworks. There is a lot of bad terminology surrounding unit testing. From TDD which testing is not its main purpose but design, to mocking frameworks which is again not a good name. I prefer what Roy Osherove calls them is his book, that is isolation frameworks. I highly recommend reading Roy Osherove’s book The Art of Unit Testing.