I’m in a dry spell for blogging, so here’s a rehash of a presentation I gave internally at work earlier this year. The general topic of mock objects comes up pretty often at our Agile Austin lunches, so I figure mocks are worth some blogging space anyway. This is the first of 4 posts on the subject of mock objects and stubs.
- Introduction to Mocks and Stubs (this post)
- When and Why to use Mocks and Stubs
- Best Practices for Mocks
- Constraints and other Mocking Tricks
- Attaching Mocks and Stubs with StructureMap (by request)
Test Driven Development always seems pretty simple in the introductory tutorials. Assert that the result of 2 + 2 equals 4, check. Then Monday morning you go back to the real world of enterprise application development and you’re suddenly faced with relational databases, middleware, web services, and all manner of security infrastructure. For a variety of reasons, interacting with external resources can make your automated tests a lot harder to write, debug, and understand. Even worse, those external resources may make your tests indeterminate (think shared database). You’ll frequently hear teams say they didn’t write unit tests for a particular area of the code because it was just too hard to test. I think one of the biggest challenges of using TDD is learning strategies for isolating the code that’s hard to test and writing code that is easy to test. One of the primary strategies to extend unit test coverage into those hard to reach places is to use mock objects, stubs, or other fake objects in place of the external resources so that your tests don’t involve the external resources at all.
One of the central pillars of Object Oriented programming is polymorphism -- the ability to interchangeably utilize multiple implementations of a well-defined interface. We’ve all seen way too many silly examples of Beagle inheriting from Dog which implements IAnimal. Here’s a more realistic and powerful utilization of polymorphism. You’re tasked with building a new reporting website to display data from the old legacy COBOL inventory system (you know, the one where the column names are COL0023 and the tables are D05A10). The legacy system team is struggling to get the data access code done because the database structure doesn’t make the slightest bit of sense. You’d like to get started with constructing the website, so you define the interface of the data access class and create a stub class that just reads data from an xml file instead of the legacy code. You can get on with your work and focus on the user interface functionality.
public interface IDataSetSource
{
DataSet FetchReport(DateTime from, DateTime to);
}
public class StubbedDataSetSource : IDataSetSource
{
public DataSet FetchReport(DateTime from, DateTime to)
{
DataSet dataSet = new DataSet();
dataSet.ReadXml("ReportData.xml");
return dataSet;
}
}
public class DataSetSource : IDataSetSource
{
public DataSet FetchReport(DateTime from, DateTime to)
{
// run a query or a stored procedure against the database and return
// a DataSet of the results
}
}
// ReportController depends on the IDataSetSource interface, not a particular
// implementation or even backend data store
public class ReportController
{
private IDataSetSource _source;
public ReportController(IDataSetSource source)
{
_source = source;
}
}
What’s the Difference between a Mock and a Stub?
Stubs have been around as long as object oriented programming and they’re well understood. Mock objects on the other hand are a relatively new concept that seems to generate a great deal of confusion. A common misconception about mocks and stubs is that the difference is that stubs are static classes and mocks are dynamically generated classes created by some kind of tool like NMock. That’s a false dichotomy. The real difference between a mock and a stub is in the style of unit testing, i.e. state-based testing versus interaction testing. A stub is a class that is hard-coded to return data from its methods and properties. You use stubs inside unit tests when you’re testing that a class or method derives the expected output for a known input.
A mock object is a tool for interaction based testing. You use a mock object to record and verify the interaction between two classes. Roy Osherove made my all time favorite explanation of mock objects by comparing a mock object to a spy that listens to the interaction between two classes.
The typical usage of a mock object is roughly the 5 step process below.
- Create the mock object
- Set the expectations on the mock object
- Create the class that’s being tested
- Execute the method that’s being tested
- Tell each mock object involved in the test to verify that the expected calls were made
Here’s an example from a model view presenter pattern using NMock to create dynamic mock objects.
[Test]
public void CloseViewWhenViewIsNotDirty()
{
// 1.) Create the mock objects
IMock msgBoxMock = new DynamicMock(typeof(IMessageBoxCreator));
IMock viewMock = new DynamicMock(typeof(IView));
// 2.) Define the expected interaction
msgBoxMock.ExpectNoCall("AskYesNoQuestion", typeof(string), typeof(string));
viewMock.ExpectAndReturn("IsDirty", false);
viewMock.Expect("Close");
// 3.) Create the presenter class with the mock objects
Presenter presenter = new Presenter(
(IView) viewMock.MockInstance,
(IMessageBoxCreator) msgBoxMock.MockInstance);
// 4.) Perform the unit of work
presenter.Close();
// 5.) Verify the interaction
msgBoxMock.Verify();
viewMock.Verify();
}
Dynamic versus Static
Both mocks and stubs can be implemented as either a dynamically emitted class or a static class that you roll on your own. Here’s an example stubbing security done both statically and dynamically.
public interface ISecurityDataStore
{
bool Authenticate(string userName, string password);
string[] GetRoles(string userName);
}
// Static stub
public class StubbedSecurityDataStore : ISecurityDataStore
{
public bool Authenticate(string userName, string password)
{
return true;
}
public string[] GetRoles(string userName)
{
return new string[]{"Admin", "Write", "Read"};
}
}
[TestFixture]
public class AuthenticationTester
{
public void AuthenticateSuccessfullyAndCreateTheCorrectPrincipal()
{
// Create a dynamic mock object for ISecurityDataStore, but use it
// like a stub. I don't call Verify() on the dataStoreStub object
// because I'm just testing the state of the GenericPrincipal object
// that is returned by authenticator
IMock dataStoreStub = new DynamicMock(typeof(ISecurityDataStore));
string[] theRoles = new string[]{"role1", "role2"};
// setup dataStoreStub.MockInstance to return theRoles anytime the "GetRoles" method
// is called
dataStoreStub.SetupResult("GetRoles", theRoles, null);
Authenticator authenticator = new Authenticator((ISecurityDataStore)dataStoreStub.MockInstance);
GenericPrincipal principal = authenticator.CreatePrincipal("Jeremy", "ComplexPassword");
Assert.IsTrue(principal.IsInRole("role1"));
Assert.IsTrue(principal.IsInRole("role2"));
Assert.IsFalse(principal.IsInRole("role3"));
}
}
We’ve already looked at several examples of dynamic mocks, so here’s an example of what a static mock for ISecurityDataStore might look like.
public class MockSecurityDataStore : ISecurityDataStore
{
private string _expectedUserName;
private string _expectedPassword;
private string[] _roles = new string[0];
private bool _authenticationSuccess = false;
private bool _authenticateWasCalled = false;
public MockSecurityDataStore(string expectedUserName, string expectedPassword, bool authenticationSuccess)
{
_expectedUserName = expectedUserName;
_expectedPassword = expectedPassword;
_authenticationSuccess = authenticationSuccess;
}
public string[] Roles
{
get { return _roles; }
set { _roles = value; }
}
public bool Authenticate(string userName, string password)
{
Assert.AreEqual(_expectedUserName, userName, "Unexpected user name");
Assert.AreEqual(_expectedPassword, password, "Incorrect password");
_authenticateWasCalled = true;
return _authenticationSuccess;
}
public string[] GetRoles(string userName)
{
Assert.AreEqual(_expectedUserName, userName, "Unexpected user name");
return _roles;
}
// Call this method to verify the Authenticate() method was called at all
public void VerifyExpectations()
{
Assert.IsTrue(_authenticateWasCalled, "The Authenticate() method was never called");
}
}
I definitely have my preferences in the static versus dynamic mock debate, but at various times I’ve used all four permutations. I like to use static mocks whenever I’m faced with a lot of name/value pairs or set based arguments. I have a static mock class in my rough equivalent of the Enterprise Library’s data access framework that validates the correct parameter values for the invocation of any database command (I still think it’s a clever implementation, but we don’t use it very often). Whatever your preference, I’d still try to be familiar with all of the options because each development project is different. By all means, don’t blow off the dynamic mock tools just because they look scary at first view.
The Case for Dynamic Mocks
My strong preference is to use dynamic mocks. A lot of people avoid using dynamic mocks because they look weird at first and maybe aren’t the easiest thing in the world to understand. I think that once you get past the initial learning curve dynamic mocking engines like NMock or RhinoMocks become easier to use. I like dynamic mocks because you don’t have to clutter up your code with a bunch of extra classes for the static mocks. Another great attribute of dynamic mocks is that you don’t have to implement the entire interface and you can essentially ignore the methods and members of the interface being mocked that aren’t involved in any particular unit test. I really get irritated when I add a new method to an interface then spend a couple minutes chasing down all of the static mocks and stubs to add skeleton methods just to get the code to compile. I also think that dynamic mocks are more flexible. I’ve also found that dynamic mocks lead to writing less code because the mocking engine takes care of the assertion logic.
The Case for Static Mocks
The single biggest reason to use static mocks is simply a discomfort with dynamic mock engines. I’ll easily grant you that the dynamic mock tools aren’t very well documented and they’re still relatively new. Micah Martin of ObjectMentor has a good post on the pro-static mock case. I don’t agree with Micah entirely, especially about his contention that mock tools aren’t flexible enough (but that’s a later post already on the way). Where he’s definitely accurate is in warning us that dynamic mocks hamper refactoring. Dynamic mocks aren’t “ReSharper-able.” The compiler and ReSharper can’t find the method references in mock.ExpectAndReturn(“SomeMethod”, true) when you change the SomeMethod() to IsSomething(). The refactoring challenge in specific is why I’m taking a long, hard look at RhinoMocks to replace NMock in our development (that little Intellisense thing is pretty important too).
There’s a more general lesson in there though. Using reflection of any kind can easily lead to brittle code that is harder to refactor.
Next up is a discussion on when and why to use mock objects…
Posted
Mon, Dec 19 2005 6:38 AM
by
Jeremy D. Miller