Stubs in Microsoft Fakes

A few weeks back, I wrote an article about using shims in Microsoft Fakes. In addition to shims, Microsoft Fakes also has support for stubs. Stubs in Microsoft Fakes works a lot like other mocking frameworks such as Rhino Mocks, and it comes with a lot of the same limitations (must be visible, must be virtual, etc.). Let’s look at an example of what we can do using stubs in Microsoft Fakes. (Note: Microsoft Fakes requires Visual Studio 2012.)

Before we can use Microsoft Fakes, we need to do a little setup. Here are the steps that need to be performed:

  1. Create a new solution/project; I’m using a C# Console Application named “FakesSample”
  2. Add a new Unit Test Project to the solution; mine is named “FakesSample.Tests”
  3. Add a reference to the project to be tested in the test project
  4. In Solution Explorer, right-click the newly created reference and choose Add Fakes Assembly

And we’ll need some code to test. This is what I’ll be using:

namespace adamprescott.net.FakesSample
{
    using System;

    public class Mammal
    {
        public string Name { get; set; }
    }

    public interface IDataAccess
    {
        Mammal Get(int id);
    }

    public class Program
    {
        static void Main(string[] args)
        {
            var p = new Program();
            p.Run();
        }

        public IDataAccess DataAccess { get; set; }

        public void Run()
        {
            var m = DataAccess.Get(1);
            Console.WriteLine(m.Name);
        }
    }
}

Create a stub

The core functionality of a stub in unit tests is to remove external dependencies and/or provide makeshift functionality. In our code above, there is an IDataAccess that’s used to retrieve Mammal objects by ID. The Microsoft Fakes stub is perfect for this. In code, we create a Mammal object to be returned, and we return it using a lambda in our stub:

var m = new Mammal { Name = "Terry" };
var stubDataAccess = new StubIDataAccess
{
    GetInt32 = x => m
};

Verify a call

The stub gives us our desired behavior, but how do we know the stub was used? We can add verification by setting a flag in our stub implementation and asserting the value after the test is executed.

var m = new Mammal { Name = "Terry" };
var wasCalled = false;
var stubDataAccess = new StubIDataAccess
{
    GetInt32 = x => {
        wasCalled = true;
        return m;
    }
};
// ...
Assert.IsTrue(wasCalled);

I like that Microsoft Fakes makes this capability available without the need of a third party, but I’ll probably be sticking with Rhino Mocks for the time being. I haven’t found anything that I couldn’t do in MS Fakes that I could do with Rhino Mocks, but it often takes a lot more code. Maybe it’s because I’m less familiar with Fakes, or maybe it’s because Rhino Mocks is a more mature mocking framework–I’m not sure.

Here’s the complete unit test example:

namespace adamprescott.net.FakesSample.Tests
{
    using adamprescott.net.FakesSample.Fakes;
    using Microsoft.VisualStudio.TestTools.UnitTesting;

    [TestClass]
    public class ProgramTest
    {
        [TestMethod]
        public void RunWritesNameToConsole()
        {
            // Arrange
            var target = new Program();

            var m = new Mammal { Name = "Terry" };
            var wasCalled = false;
            var stubDataAccess = new StubIDataAccess
            {
                GetInt32 = x =>
                {
                    wasCalled = true;
                    return m;
                }
            };
            target.DataAccess = stubDataAccess;

            // Act
            target.Run();

            // Assert
            Assert.IsTrue(wasCalled);
        }
    }
}
Advertisements

One thought on “Stubs in Microsoft Fakes”

  1. I have found that putting Console.Writeline calls in my tests can help me see the results of my tests as well. They can show not just what order my fakes are called in, but they can also show how many times they were called. When the test is run and you look at the test explorer, you will see an output link that contains anything that was written to the console or to Debug. The reason I recommend Console instead of Debug is that Debug writes don’t get compiled in when you compile in release, but the Console calls do.

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s