posted on Thursday, October 06, 2005 6:40 PM
by
anoras
Mock objects: Sealed doesn’t suck as much as it used to.
Back in 2003 Chris Sells wrote a blog post called
”Sealed
Sucks” on the pros and cons of sealing a class. When I recently wrote some
tests for an OR-mapping framework, I shared Chris’ feelings on the
sealed
keyword. The reason was simple, I had a class which mapped objects to stored
procedures that exposed a single method to persist objects, and I had to ensure
that the correct procedure was called, the correct parameters where passed to
the procedure and so forth. The OR-mapper’s constructor expected a
SqlConnection object as its parameter, so I figured that I’d just pass it a
mocked
SqlConnection.
NMock has been my tool of choice for mocking objects, but since SqlConnection
is a sealed class you’ll get an exception if you try to mock it using NMock. Writing
a mock SqlConnection by hand is neither an option, because you won’t be able to
cast it to a SqlConnection.
Luckily, I came across a nifty mocking framework called TypeMock.NET which has the ability to mock any member
of any concrete class, no matter whether the members are non-virtual or private,
or the class is sealed. TypeMock.NET uses AOP-like techniques at the IL level
to intercept usages of any type and member. It does this by using the .NET Framework’s
profiler API to monitor execution. When the CLR loads a method, TypeMock.NET replaces
the IL with calls to the mocked code.
Below is an example of how to assert that an a SqlParameter
with the appropriate customer id is added to a SqlCommand’s Parameters
collection when a Customer object is persisted.
[TestFixture]
public class DataServiceTest
{
[SetUp]
public void
Setup()
{
MockManager.Init();
}
[Test]
public void
TestDataService()
{
Customer
customer=new Customer();
customer.Id="42";
string
connectionString="Mock Connection String";
Mock
mockSqlConnection=MockManager.Mock(typeof(SqlConnection));
mockSqlConnection.ExpectConstructor().Args(connectionString);
Mock
mockSqlCommand=MockManager.Mock(typeof(SqlCommand));
Mock
mockSqlParameterCollection=MockManager.Mock(typeof(SqlParameterCollection));
mockSqlParameterCollection.ExpectAndReturn("Add",1).Args("CustomerID",customer.Id);
mockSqlCommand.ExpectCall("ExecuteNonQuery",1);
mockSqlConnection.ExpectAndReturn("CreateCommand",new
SqlCommand());
DataService
dataService=new DataService(new SqlConnection(connectionString));
dataService.SaveObject(customer);
}
[TearDown]
public void
TearDown()
{
MockManager.Verify();
}
}
There are a couple of things to take note of in the above
example. When I register mock objects for the SqlConnection, SqlCommand and
SqlParameterCollection types, the actual mock objects aren’t created until I instantiate
a new instance of either of the classes. This is the reason why I return an
actual SqlCommand instead of a mock object in my mock implementation of
SqlConnection.CreateCommand. Further, I do not need to manually create an
instance of the SqlParameterCollection, because this class will automatically
be mocked when the SqlCommand creates is Parameters collection.
Finally, I have to call the MockManger.Verify method to
assert that all of my expectations have been fulfilled. This is akin to using
Assert statements in a regular NUnit test.
Thanks to TypeMock.NET sealed doesn’t suck as much as it
used to.