130CHAPTER 5 Isolation (mock object) frameworks

5.9Current isolation frameworks for .NET

Rhino Mocks is certainly not the only isolation framework around. But in an informal poll held March 2009, I asked my blog readers, “Which isolation framework do you use?” Close to 46 percent of the more than 600 people who responded reported using Rhino Mocks, 20 percent were using Moq, and 7 percent were using Typemock. (See figure 5.2.)

Figure 5.2 Usage of isolation

frameworks among

my blog readers

What follows is a short review of the current isolation frameworks in

.NET. It’s usually a good idea to pick one and stick with it as much as possible, for the sake of readability and to lower the learning curve for team members. The information that follows should help you make a choice, but note that each of the frameworks mentioned (especially the top three) can add new features at an alarming pace, so the choice of what’s best for your team will seem to be in a constant state of flux.

5.9.1NUnit.Mocks

NUnit.Mocks is an internal side project of the NUnit framework. It was originally created to provide a simple, lightweight isolation framework that could be used to test NUnit itself, without having to rely on

Current isolation frameworks for .NET

131

external libraries and version dependencies. Part of NUnit is open source, but it was never regarded as public, so there’s little or no documentation about using it on the web today. Charlie Poole, the current maintainer of NUnit, has said that he is considering either removing it completely from the distribution of NUnit or making it public in version 3.0 of NUnit.

Here are a few of the limitations of NUnit.Mocks:

It doesn’t support stub syntax.

It requires strings to expect calls on method names.

It has no support for testing or firing events.

It doesn’t support parameter constraints (expected parameter values that are hardcoded in the test).

5.9.2NMock

NMock is a port of the jMock framework from the Java language. As such, it has been around quite a long time and has many users. It has been largely unmaintained since early 2008 because the developers have gone to work on something bigger and better: NMock2. NMock is open source.

NMock supports the stub syntax but still requires strings for method name expectations. It has no event-raise or test support, but it does support parameter constraints.

5.9.3NMock2

NMock2 is a large leap forward from NMock. The APIs have changed greatly to accommodate a more fluent calling interface. NMock2, unfortunately, at the time of this writing, has been largely unmaintained since early 2008 and has only come back into some sort of update cycle in 2009, which has driven many people away from using it. NMock2 is open source.

NMock2 supports most, if not all, of the features that Rhino Mocks has, with the main difference being that method expectations are stringbased in NMock2, whereas in Rhino Mocks they’re call-based. (You

132

CHAPTER 5

Isolation (mock object) frameworks

call the method as part of the recording process.) NMock2 also features parameter constraints, event-related assertions, and callback abilities.

5.9.4Typemock Isolator

Typemock Isolator is a commercial isolation framework, although there’s a free edition with the same features for use in open source project development. Because it’s commercial, it also has good documentation that’s always up to date, a support program, and continually updated versions. Isolator is a perfect fit for testing not only new code but also legacy code (untested, existing code) where testing can be impossible in many situations.

Typemock Isolator builds on top of the abilities of the other frameworks, and it also allows mock (called “fake” in the Isolator API) classes that have private constructors, static methods, and much more. It does this by attaching to the .NET profiler APIs—a set of APIs that allow you to intercept a call to anything, anywhere, including private members, statics, and events. Anything that goes on in the .NET runtime can be intercepted. Typemock Isolator has raised quite a stir in the unit-testing and isolation world of .NET. Some people claim that it may be too powerful, because it makes it easy to simulate and break the dependencies of any object in your existing code. In that way, it doesn’t force you to think about how your design might need to change.

Others feel that it provides a sort of bridge for getting started with testing even if the design is untestable, allowing you to learn better design as you go, instead of having to refactor and learn better design skills before testing. If you can’t mock an object in your code, it can mean that the design could be improved to be more decoupled. That’s why many people like to use their tests to flush out design problems. Appendix A discusses this issue.

5.9.5Rhino Mocks

Rhino Mocks was first released in June 2005, and has gained a massive user base already. It’s open source, is continuously being worked upon, and has frequent releases. Currently, it’s maintained by a single developer (who seems to have no life whatsoever). It has powerful APIs,

Current isolation frameworks for .NET

133

and one of the things it’s most noted for is avoiding the use of strings inside tests. To understand why strings in tests are bad, see the sidebar.

Why method strings are bad inside tests

The best way to explain this is to look at an example of using NUnit.Mocks and Rhino Mocks to do the same thing. We’ll see the differences in using strings for method names and using the isolation framework syntax.

We’ll mock the following interface:

interface ILogger

{

void LogError(string msg, int level, string location);

}

First, we’ll look at how we’d mock this interface using NUnit.Mocks:

//Using NUnit.Mocks

DynamicMock mock = new DynamicMock(typeof(ILogger)); mock.Expect("LogError",

"param value 1	is	string",	? Uses a string
2,
"param value 3	is	a string	as well");

ILogger myMockInterface = mock.MockInstance as ILogger;

MytestedClass.SetLogger(myMockInterface);

The Rhino Mocks code looks different:

//Using Rhino.Mocks

MockRepository mocks = new MockRepository();

ILogger simulatedLogger = mocks.StrictMock<ILogger>();

simulatedLogger.LogError("param value 1 is a string", 2,		Uses
"param value 3 is a string");	w a strongly
mocks.ReplayAll();		typed call
MyTestedClass.SetLogger(simulatedLogger);
MyTestedClass.DoSomething();
mocks.VerifyAll();

Notice how lines ?and ware different in these two versions. If we were to change the name of the LogError method on the ILogger interface, any tests using NUnit would still compile and would only break at runtime, throwing an exception indicating that a method named LogError could not be found.