Following on from my mocking framework comparison, I changed Twiddler (my pet Twitter client project) from Moq to NSubstitute, and from xUnit.net's built-in Asserts to Should.Fluent, and I think both changes greatly improved readability of my tests.

Full diffs are here for comparison:

• Moq → NSubstitute
• xUnit.net Assert → Should.Fluent

Permalink | Leave a comment  »

What's the collective noun for mocking frameworks? If there is one, then .NET has it!

I've used Moq for years but I'm always keen to make my tests more readable, so I thought it was time to compare some of the modern alternatives and see how they perform in a test fixture plucked almost at random from a project I recently worked on. So, here are the same tests using fakes from Moq, NSubstitute and FakeItEasy, all of which are available from the NuGet gallery. If there's another hot framework you think compares well then let me know and I'll try it out too.

Disclaimer: I'm quite familar with Moq but this is my first time with NSubstitute and FakeItEasy, so I'm not necesarily using the best option for these frameworks. If you spot something that would be better done in another way, fork the Gist on GitHub and let me know!

Setup

I use xUnit.net which works slightly differently to most of the other test frameworks: it creates a new instance of your test fixture class for each test, which allows you to use field initializers and a constructor to set up your fakes. I take advantage of this in the following snippets.

Moq

Most of the time we can use a LINQ query to set up a fake with Moq. This leads to nice and clean test set up as it can be done from a field initializer if you have setup that applies to all the tests in the fixture:

1
2
3
4
5
6
7
8
9
10

public class MyFixture
{
    private readonly ICloseLogFileCommand _closeCommand = Mock.Of<ICloseLogFileCommand>();

    private readonly ILog _log = Mocks.Of<ILog>().
        First(x => x.Name == @"C:\Path\To\File.log" &&
                   x.Count == 42 &&
                   x.Offset == TimeSpan.FromSeconds(69));
    ...
}

Quite succinct, no constructor needed, but a little bit ugly.

NSubstitute

The instantiation of the fakes is very similar to Moq, but there is no equivalent to the LINQ setup so we need a constructor:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class MyFixture
{
    private readonly ICloseLogFileCommand _closeCommand = Substitute.For<ICloseLogFileCommand>();

    private readonly ILog _log = Substitute.For<ILog>();

    public MyFixture()
    {
        _log.Name.Returns(@"C:\Path\To\File.log");
        _log.Count.Returns(42);
        _log.Offset.Returns(TimeSpan.FromSeconds(69));
    }
    ...
}

I find this very readable, and it's probably easier to understand than the LINQ setup.

FakeItEasy

Slightly different take on instantiation, and again the setup needs to be done in a constructor:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class MyFixture
{
    private readonly ICloseLogFileCommand _closeCommand = A.Fake<ICloseLogFileCommand>();

    private readonly ILog _log = A.Fake<ILog>();

    public MyFixture()
    {
        A.CallTo(() => _log.Name).Returns(@"C:\Path\To\File.log");
        A.CallTo(() => _log.Count).Returns(42);
        A.CallTo(() => _log.Offset).Returns(TimeSpan.FromSeconds(69));
    }
    ...
}

The setup reads well, but is verbose when compared to NSubstitute.

Verification

In the following snippets we have a field referencing the fake object, and we want to verify that a method was called on it.

Moq

We get the Mock for the fake object and verify:

1
2
3
4
5
6
7
8

[Fact]
public void Initialize_Always_InitializesParserPresenter()
{
    LogPresenter test = BuildTestSubject();
    test.Initialize();

    Mock.Get(_parserPresenter).Verify(x => x.Initialize());
}

Getting the Mock degrades readability a bit, but not bad.

NSubstitute

1
2
3
4
5
6
7
8

[Fact]
public void Initialize_Always_InitializesParserPresenter()
{
    LogPresenter test = BuildTestSubject();
    test.Initialize();

    _parserPresenter.Received().Initialize();
}

Wow. Couldn't really be any shorter, could it? My only criticism is that it doesn't scream "ASSERTION!!!" to me.

FakeItEasy

1
2
3
4
5
6
7
8

[Fact]
public void Initialize_Always_InitializesParserPresenter()
{
    LogPresenter test = BuildTestSubject();
    test.Initialize();

    A.CallTo(() => _parserPresenter.Initialize()).MustHaveHappened();
}

I like the way the fake is incorporated into the the call, it's much less intrusive than Moq. Ending with MustHaveHappened makes a pretty clear statement that verification is happening here.

Raising an event

In this test I want to check that the presenter raises its PropertyChanged event when the model's PropertyChanged event is raised. I'm making use of a handy extension method from Caliburn.Testability that lets me write AssertThatChangeNotificationIsRaisedBy([property]).When([something happens]). In this case [something happens] is going to be the PropertyChanged event being raised on the model, and we're going to see how that is done with the different mocking frameworks.

In the interests of staying DRY, I usually make an extension method of my own to raise PropertyChanged, but I won't here so we can see how the frameworks work!

Moq

Again we have to get the Mock, then we call Raise on it:

1
2
3
4
5
6
7
8
9
10
11

[Fact]
public void Offset_WhenLogOffsetChanges_RaisesPropertyChanged()
{
    LogPresenter test = BuildTestSubject();

    test.Initialize();

    test.AssertThatChangeNotificationIsRaisedBy(x => x.Offset).
        When(() => Mock.Get(_log).Raise(x => x.PropertyChanged += null, 
                                        new PropertyChangedEventArgs("Offset")));
}

Still not keen on getting the Mock, and it's a shame we have to write += null just to make a valid expression. Bit long and nasty.

NSubstitute

1
2
3
4
5
6
7
8
9
10
11

[Fact]
public void Offset_WhenLogOffsetChanges_RaisesPropertyChanged()
{
    LogPresenter test = BuildTestSubject();

    test.Initialize();

    test.AssertThatChangeNotificationIsRaisedBy(x => x.Offset).
        When(() => _log.PropertyChanged += Raise.Event<PropertyChangedEventHandler>(this, 
                                                                                    new PropertyChangedEventArgs("Offset")));
}

So close to being very nice, but spoiled by having to supply the generic argument to Raise. This isn't always the case, but as the PropertyChanged event is declared with a delegate it's necessary here. Still, it reads fairly well, certainly better than having += null in the middle.

FakeItEasy

1
2
3
4
5
6
7
8
9
10

[Fact]
public void Offset_WhenLogOffsetChanges_RaisesPropertyChanged()
{
    LogPresenter test = BuildTestSubject();

    test.Initialize();

    test.AssertThatChangeNotificationIsRaisedBy(x => x.Offset).
        When(() => _log.PropertyChanged += Raise.With(new PropertyChangedEventArgs("Offset")).Now);
}

A lot shorter than NSubstitute and more readable than Moq, I think that's quite good. Although at first glance the Now on the end seems a bit odd.

Conclusion

Each of these frameworks has a lot more to offer than I've touched on here, covering just about anything you could do to an object (and probably a few things you wouldn't want to!). I wanted to see what the basic, everyday scenarios look like as those are the ones that really matter to me, and after this I will definitely try NSubstitute out on a real project.

It's amazing how far mocking frameworks have come in the last couple of years!

Permalink | Leave a comment  »

How did it happen?

public class MyClass : INotifyPropertyChanged
{
    private string _name;

    public string Name
    {
        get { return _name; }
        set
        {
            _name = value;
            PropertyChanged(this, new PropertyChangedEventArgs("Name"));
        }
    }

    public event PropertyChangedEventHandler PropertyChanged = delegate { };
}

[TestFixture]
public class MyClassTestFixture
{
    [Test]
    public void Name_WhenSet_RaisesPropertyChanged()
    {
        var test = new MyClass();

        test.AssertThatChangeNotificationIsRaisedBy(x => x.Name);
    }
}

error : Internal error: An unhandled exception occurred. error : System.Exception: No context was provided to test the notification, use When(Action affectProperty) to provide a context. error :    at Caliburn.Testability.Assertions.PropertyHasChangedAssertion`2.Finalize()

~PropertyHasChangedAssertion()
{
    if(!_isValidAssertion)
        throw new Exception(
            "No context was provided to test the notification, use When(Action affectProperty) to provide a context.");
}

[Test]
public void Name_WhenSet_RaisesPropertyChanged()
{
    var test = new MyClass();

    test.AssertThatChangeNotificationIsRaisedBy(x => x.Name)
        .When(() => test.Name = "New name");
}

What went wrong?

1. I write the test, and add an empty property definition to make it compile
2. I run the test and see that it unexpectedly passes
3. I scratch my head for a bit, but I’m already looking at the offending line of code so it’s much easier to spot the problem
4. The penny drops, I spot the mistake and fix it
5. I run the test again, and this time it fails. Happy days.
6. I implement the property changed notification and carry on

It could have been worse!

A lesson learned?

Permalink | Leave a comment  »

The Story So Far

Where am I now?

Does it work?

Permalink | Leave a comment  »

1. Outdated technical posts that would be downright misleading now;
2. Personal stuff that the Interwebs should not be interested in;
3. Links auto-posted from my Del.icio.us account;
4. Factually inaccurate bullshit.

So what now?

1. I start off well, with a couple of posts about test driven development and the like;
2. The posts get shorter and shorter and are spaced farther and farther apart;
3. In a year’s time I’ve all but forgotten about it when the hosting charge is applied to my debit card, for which my wife never forgives me.

Permalink | Leave a comment  »