134

CHAPTER 5

Isolation (mock object) frameworks

With Rhino Mocks, changing the name would not be a problem, because we’re invoking the method API as part of our recording stage. Any method changes would keep the test from compiling, and we’d know immediately that there was a problem with the test.

With automated refactoring tools like those in Visual Studio 2005 and 2008, renaming a method is easier, but most refactorings will still ignore strings in the source code. (ReSharper for .NET is an exception. It also corrects strings, but that’s only a partial solution that may prove problematic in some scenarios.)

5.9.6Moq

Moq is a relatively new framework. It requires using .NET 3.5 because it uses lambda constructs to work its magic. It’s simple to use if you’re comfortable with lambda syntax, but it will only work on interface types and classes that are nonsealed with virtual methods. Unlike Rhino Mocks, it does allow you to fake protected methods.

Let’s recap the advantages of using isolation frameworks over handwritten mocks. Then we’ll discuss things to watch out for when using isolation frameworks.

5.10 Advantages of isolation frameworks

From what we’ve covered in this chapter, we can see some distinct advantages to using isolation frameworks:

Easier parameter verification—Using handwritten mocks to test that a method was given the correct parameter values can be a tedious process, requiring time and patience. Most isolation frameworks make checking the values of parameters passed into methods a trivial process even if there are many parameters.

Easier verification of multiple method calls—With manually written mocks,

it can be difficult to check that multiple method calls on the same method were made correctly with each having appropriate different parameter values. As we’ll see later, this is a trivial process with isolation frameworks.