I regret not having blogged on TDD and designing for test before – it makes it very difficult to talk about mocking as it is a rather advanced topic, requiring at least some knowledge of polymorphism and oo-design.
So this post is the first in a series of posts on the topic of testing with mock objects, that will hopefully help you with your testing.
Testing is one of the most important things in software development.
We’re all human, and we all make mistakes. And even if we discover these mistakes during development and testing, it’s almost certain that we’ll have to come back at a later point to change something, possibly breaking what already worked.
Doing a full QA cycle during initial development may look reasonable to most of us, but doing it every time you change a tiny bit in the application will certainly get you some angry mails from management.
Having good unit tests gives you a safety net for future development. By simply running the tests you can verify that things that already worked still work properly. And that’s what is important in software development.
The whole idea of unit testing is to test as little as possible while still verifying that the method under test behaves as specified and expected.
Keep this in mind, because it is important when testing classes that depend on services or other classes.
If let’s say you have a HttpServiceWatcher that is a service running somewhere and watching if a HttpService is up and running, you should test the HttpServiceWatcher class itself, not the associated notifier classes that the Watcher calls when it wants to notify you.
But how do you verify that the HttpServiceWatcher really worked and called the notifier as a result?
Let’s start with the Notifier interface:
public interface IErrorNotifier
{
void NotifyOfServiceDown();
}
Let’s assume we have implemented a EmailNotifier class, if the HttpServiceWatcher looks like this we’re in testing-nightmare land:
public class HttpServiceWatcher
{
public void ObserveService()
{
IErrorNotifier notifier = new EmailNotifier();
notifier.NotifyOfServiceDown();
}
}
The HttpServiceWatcher news up it’s notifier service, so every time we want to adjust the notifier, we’d have to change the ServiceWatcher and risk breaking something. Also, we can’t test the ServiceWatcher itself, because it will always call to an EmailNotifier that we can’t fake easily.
So, the correct move would be to use Inversion of Control (IoC) to inject the service into the watcher class:
public class HttpServiceWatcher
{
private IErrorNotifier notifier;
public HttpServiceWatcher(IErrorNotifier notifier)
{
this.notifier = notifier;
}
public void ObserveService()
{
notifier.NotifyOfServiceDown();
}
}
Now, the HttpServiceWatcher class doesn’t directly depend on any concrete implementation of IErrorNotifier, the calling code takes care of creating the concrete classes. Changes to notifiers don’t get propagated to the HttpServiceWatcher.
Also, this makes it very easy to simply fake the notifier. We could either create a fake test class that inherits IErrorNotifier, or we could use a Mocking framework.
Manual mocking could look like this:
public class NotifierMock : IErrorNotifier
{
public int notifyOfServiceDownCallCount = 0;
public void NotifyOfServiceDown()
{
notifyOfServiceDownCallCount++;
}
}
The test could then look like this:
[Test]
public void ServiceWatcherNotifiesUser_Custom_Mock()
{
var notifier = new NotifierMock();
var watcher = new HttpServiceWatcher(notifier);
watcher.ObserveService();
Assert.AreEqual(1, notifier.notifyOfServiceDownCallCount);
}
And that’s fine. It works, we verify that the watcher actually calls the notifier service, and all is well.
It just gets tricky when you get more tests, you’ll have to create many mock objects that always introduce the possibility of breaking other tests etc.
In the next post in this series I will try to illustrate how to do the same thing with RhinoMocks and how it makes testing very easy.
Download the source code from my SVN Repository by doing a:
svn checkout https://office.pixelpoint.at:8443/svn/tigraine/UnitTesting/trunk UnitTesting –username guest
Continue reading Unit testing with mocks – Rhino Mocks basics (Part 2)
