Foundations of Programming - Karl Seguin

Chapter 5 - Unit Testing
If we changed our Save function to throw an exception if the returned id was invalid, our test would
look like:
[TestFixture]
public class CarTest
{
private MockRepository _mocks;
private IDataAccess _dataAccess;
}
[SetUp]
public void SetUp()
{
_mocks = new MockRepository();
_dataAccess = _mocks.CreateMock();
ObjectFactory.InjectStub(typeof(IDataAccess), _dataAccess);
}
[TearDown]
public void TearDown()
{
_mocks.VerifyAll();
}
[Test, ExpectedException("CodeBetter.Foundations.PersistenceException")]
public void SaveCarCallsSaveWhenNew()
{
Car car = new Car();
Expect.Call(_dataAccess.Save(car)).Return(0);
_mocks.ReplayAll();
car.Save();
}
In addition to showing how you can test for an exception (via the ExpectedException attribute),
we’ve also extracted the repetitive code that creates, sets up and verifies the mock object into the
SetUp and TearDown methods.
More on nUnit and RhinoMocks
So far we’ve only looked at the basic features offered by nUnit and RhinoMocks, but there’s a lot more
that can actually be done with them. For example, RhinoMocks can be setup to ignore the order of
method calls, instantiate multiple mocks but only replay/verify specific ones, or mock some but not
other methods of a class (a partial mock).
Combined with a utility like NCover, you can also get reports on your tests coverage. Coverage basically
tells you what percentage of an assembly/namespace/class/method was executed by your tests. NCover
has a visual code browser that’ll highlight any un-executed lines of code in red. Generally speaking, I
dislike coverage as a means of measuring the completeness of unit tests. After all, just because you’ve
executed a line of code does not mean you’ve actually tested it. What I do like NCover for is to highlight
any code that has no coverage. In other words, just because a line of code or method has been executed
Foundations of Programming Copyright © Karl Seguin www.codebetter.com
41