I’ve been working on a new MVC project and man has it been enlightening!  It’s my first MVC project, so I get to go through all the things I thought I knew from reading Pro ASP.NET MVC Framework (Apress by Steve Sanderson) to realizing I don’t know squat,and have to really delve into the learning in order to finish the project, a task which I knew I was getting into and greatly accept the challenge.  Anyway, as I’ve been developing, I’ve been trying to use Moq to create my unit tests.  It’s a free mocking library that enables you to write code that mocks your existing objects.  While most libraries heavily use interfaces for writing mocks, Moq can mock classes that have the methods or properties to override marked as virtual (and there are some other conditions as well; you can see an example on Stephen Walther’s blog).  As you can see, Moq is great and is useful for MVC applications, and can be used in web forms in a more limited fashion.

TypeMock, however, offers you a few more conveniences over mocking.  For instance, Moq doesn’t support mocking static methods, internal methods, and a few other scenarios.  In fact, Moq is a good approach if you design software using the DI pattern, as is illustrated below:

public class TestClass
     public TestClass(IDependency dep) { }

This is where a dependency is passed in to the constructor (or it can be via a property), which Moq can setup easily as in the following code:

var depFake = new Mock<IDependency>();
//Setup any mocking here

var tc = new TestClas(depFake.Object); //fake gets inserted here
// tc.Dep = depFake.Object; <– this is an alternative approach

However, TypeMock allows you to use other approaches as well, which fits closer to my development style.  For instance, suppose you have this type of class that uses the dependency:

public class TestClass
    private TestClass() { }

    public static TestClass Create()
         var c = new TestClass();
         c.Dep = DepResolver.Get();

         return c;

With Moq, we have no inherent way to tap into this method.  This is where TypeMock comes in.  TypeMock allows us to tap into this method a couple of ways.  First, we could skip the Create method altoghether using:

var tc = Isolate.Fake.Instance<TestClass>();
Isolate.WhenCalled(() => TestClass.Create()).WillReturn(tc);

The first line creates our fake, similar to Moq’s “new Mock<TestClass>” syntax.  Rather than returning a proxy, it returns an actual instance of our mocked class.  The second statement provides a way to override the static method and return directly our fake.  This may not be as useful, so let’s look at the next way to tap into this method:

var dep = Isolate.Fake.Instance<IDependency>();
Isolate.WhenCalled(() => DepResolver.Get()).WillReturn(dep);

var tc = TestClass.Create();

When this code runs, the TestClass instance is actually created, and that code works as is.  But the code revolving around the IDependency is faked, so that the DepResolver returns our fake and doesn’t actually run.  So you can see some of the ways that TypeMock allows developers to tap into their code without forcing a design.  We’ll look at other ways this can happen later on.

Note: This doesn’t mean Moq is bad by any means; designing your software for testability is a good thing, as it’s good to leverage unit tests to ensure accuracy of your code doing what it was supposed to do.  It’s just that TypeMock gives you a few other options, and this is one of the additional features that TypeMock provides.