Your code should be unit tested. Most of the time this is a straight forward process. Using Dependency Injection, and tools like Moq can get you 90% of the way there.

In this article I will be outlining the very basics of Unit Testing using Moq, Microsoft Test Tools, Microsoft Fakes and cover a problem with Fakes where obscure .NET Framework Class Library classes aren’t accessible.

Stubs

Stubs provide a substitute concretion for interfaces used in code that requires testing. Following the Dependency Inversion Principal outlined in SOLID code design:

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

Let’s look at an example:

public interface IBar

{

string WhatDoISay();

}

public class Bar : IBar

{

public string WhatDoISay()

{

return "barbar";

}

The class Bar contains the method WhatDoISay which returns a string. Our interface IBar contains the contract for the method WhatDoISay. Any class that inherits from IBar must implement WhatDoISay or the compiler will throw an error.

public class Foo

{

public string Speech { get; set; }

public void Run(IBar bar)

{

Speech = bar.WhatDoISay();

}

Foo takes in the interface of IBar as a parameter. Since an interface cannot be instantiated it must be a pointer to a concrete class that implements IBar’s method, in particular WhatDoISay. After calling WhatDoISay the returned result is written to the Console.

Finally we have the entry point of the application, Program.

class Program

{

static void Main(string[] args)

{

IBar bar = new Bar();

Foo foo = new Foo();

foo.Run(bar);

Console.WriteLine(foo.Speech);

Console.ReadLine();

}

Program creates an instance of Foo and Bar. It then passes bar into Foo’s Run method and display’s its Speech property.

The result is to display “barbar.”

Let’s test this.

Right click on your Solution and select Add -> New Project.
In the left side project tree navigate to Visual C# -> Test.
Select Unit Test Project and give it a name, preferably the project name with .Test at the end.
Click Ok.

We now have a Test Project.

Before we can start testing our class Foo we have to add a reference to the project where it’s located.

Right click on Reference in the Solution Explorer and Select Add Reference….

Select Solution -> Projects -> TestApp and click OK.

Let’s create a file where the testing will take place.

Right click on the project, select Add -> Unit Test… and rename the file to FooTest.cs.

using System;

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace TestApp.Tests

{

[TestClass]

public class FooTest

{

[TestMethod]

public void TestMethod1()

{

}

TestMethod1 is where we will put our code to Test Foo but first let’s name it something a little more appropriate.

[TestMethod]

public void WhatDoISay_ReturnAValidString_RunsCorrectly()

Since we will have many tests for each method inside of our class we should be specific about the name of the method to be tested, input and or important details and the expected outcome.

For our first unit test we want to make sure a different string is written to the console. Let’s create a Stub class that will output a different string, then make sure that string was set to the Property Speech in Foo.

public class FakeBar : IBar

{

public string WhatDoISay()

{

return "fakebarbar";

}

Now let’s set up our test.

[TestMethod]

public void WhatDoISay_ReturnAValidString_RunsCorrectly()

{

Foo target = new Foo();

FakeBar fakeBar = new FakeBar();

target.Run(fakeBar);

Assert.AreEqual(target.Speech, "fakebarbar");

}

We create the “target” to test, which in this case is an instance of Foo, instantiate FakeBar, pass it into the target’s Run method and Assert that target’s Speech property got set to our desired string.

What if we want to track the number of times WhatDoISay got called? It should be simple enough to add a counter to the FakeBar class and increment it every time WhatDoISay gets called.

[TestClass]

public class FooTest

{

[TestMethod]

public void WhatDoISay_ReturnAValidString_RunsCorrectly()

{

Foo target = new Foo();

FakeBar fakeBar = new FakeBar();

target.Run(fakeBar);

Assert.AreEqual(target.Speech, "fakebarbar");

Assert.AreEqual(fakeBar.NumberOfTimesWhatDoISayGotCalled, 1);

}

public class FakeBar : IBar

{

public int NumberOfTimesWhatDoISayGotCalled = 0;

public string WhatDoISay()

{

NumberOfTimesWhatDoISayGotCalled++;

return "fakebarbar";

}

I now want to test what happens when I throw an error. I have to create another FakeBar that’s WhatDoISay method throws an exception. At this point it should be obvious this gets messy very, very quickly. This is where Moq comes in.

Moq is Mocking Framework that provides capable stubs with features accessed using lambda statements. Not only does this make designing stub behavior easy, it also makes your code more readable.

Let’s rewrite our last example using Moq.

In our Test project right click on References and select Manage NuGet Packages….

Type Moq in the upper right corner search field. When the search is done click on the Install button next to “Moq: an enjoyable mocking library” and close it.

We now have a reference to our Moq library.

Let’s get started.

Add using Moq; to the top of your test file.

using System;

using Moq;

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace TestApp.Tests

We’re going to do a few things in the code below:

Replace FakeBar with its mock.
Setup the desired behavior when WhatDoISay is called.
Pass its object into target’s run method.
Check the number of times WhatDoISay gets called.

[TestMethod]

public void WhatDoISay_ReturnAValidString_RunsCorrectly()

{

Foo target = new Foo();

Mock<IBar> barMock = new Mock<IBar>();

barMock.Setup(m => m.WhatDoISay()).Returns("fakebarbar");

target.Run(barMock.Object);

Assert.AreEqual(target.Speech, "fakebarbar");

barMock.Verify(m => m.WhatDoISay(), Times.Once());

}

One extra line of code in the method to get rid of our FakeBar class implementation.

Let’s test what happens when we throw an exception.

[TestMethod]

public void WhatDoISay_ThowsAnException_ExceptionCaught()

{

Foo target = new Foo();

Mock<IBar> barMock = new Mock<IBar>();

barMock.Setup(m => m.WhatDoISay()).Throws(new Exception());

bool exceptionCaught = false;

try

{

target.Run(barMock.Object);

}

catch

{

exceptionCaught = true;

}

Assert.AreEqual(exceptionCaught, true);

barMock.Verify(m => m.WhatDoISay(), Times.Once());

}

Again, no extra class had to be created to throw the exception and we are still free to see the results.

Shims

What happens when you have code that has not been interfaced out? Interfacing every .NET Framework Class library would be time consuming and annoying. It would also overly complicate your code base.

Let’s take a look at this in action.

public class Baz

{

public bool DoesDirectoryExist { get; set; }

public void Run()

{

string path = "C:\\temp\\";

DirectoryInfo directoryInfo = new DirectoryInfo(path);

DoesDirectoryExist = directoryInfo.Exists;

}

class Program

{

static void Main(string[] args)

{

Baz baz = new Baz();

baz.Run();

Console.WriteLine(baz.DoesDirectoryExist);

Console.ReadLine();

}

Baz calls DirectoryInfo’s Exists method and stores the value in its DoesDirectoryExist property.

DirectoryInfo is now a dependency whose behavior we can’t control because:

It was not interfaced out.
It was not injected.

What if we want to test DirectoryInfo throwing an Exception? Microsoft Fakes to the rescue.

“Microsoft Fakes help you isolate the code you are testing by replacing other parts of the application with stubs or shims.”

Let’s create shims of the .NET Framework System library.

Right click on the System library under Reference and select Add Fakes Assembly.

It will take a few moments to generate your fakes.

You will now have 2 new libraries under References:

mscorlib.4.0.0.0.Fakes
System.4.0.0.0.Fakes

We also have a Fakes folder containing:

mscorlib.fakes
System.fakes

Where the hell is System.IO.Path?

I ran into this annoying problem with Microsoft Shims and Fakes.

One more code example:

public class Qux

{

public string FilePath { get; set; }

public void Run()

{

string fileName = "a.pdf";

string path = "C:\\a\\";

FilePath = Path.Combine(path, fileName);

}

class Program

{

static void Main(string[] args)

{

Qux qux = new Qux();

qux.Run();

Console.WriteLine(qux.FilePath);

Console.ReadLine();

}

Qux uses Path.Combine to smooth over any missing slashes when combining parts of a path.

Let’s go unit test this.

Where the hell is Path? What about FileInfo’s Extension method?

It turns out when MS Fakes goes through and shims a library it doesn't shim every class. Any methods not shimmed on the first try have to be specified somewhere else.

Path is a static class and FileInfo’s Extension method is inherited from its base class, FileSystemInfo.

Remember our .fakes files?