Mocking frameworks are growing more and more in popularity these days, because to some degree Unit Testing, via TDD or otherwise, has been growing in popularity. This week at the Heartland Developer Conference I gave a talk on what I call "practical" TDD. The talk goes over the basics of TDD quickly, but is really targeted at those who have tried to do TDD but found it difficult because they are not working on a team that has adopted the practice, or they are not working a project that was built to be testable. I spent a good bit of time working no what is the easiest path to help such people adopt TDD, because adoption of such good practices is far more important to me than perfection in them. As has been said many times, Good Enough is by definition, Good Enough.
After a good bit of research on the subject of mocking frameworks, I have come to the simple conclusion that:
- This is an area that is growing still, as nearly every major framework differs on the coding approach. This is in stark contrast to testing frameworks which, to a one in .NET, all have settled on the NUnit 2.0 model of using attributes.
- That if you're not using TypeMock then you're just working to damned hard.
Now, I'm sure my friends (and there are many) who use Rhino Mocks will believe that I must be over-stating the issue, but I tell you clearly I am not. TypeMock is not built like any other mocking framework currently available, it uses the profiling APIs and not polymorphism or encapsulation in order to intercept calls and provide return values. Let me give you just a few examples of things which TypeMock can do in a few short lines of code which Rhino Mocks simply cannot do at all.
Mocking Static Methods
Take the following code, and assume that we wish to mock MessageBox.Show which is a static method:
private void MyCoolMethod(string msg)
{
if (MessageBox.Show(msg) == DialogResult.OK)
Console.WriteLine("OK");
else
Console.WriteLine("Not OK! Not OK!");
}
The following test will work perfectly to mock this call. No other hidden setup, nothing more than a reference to TypeMock.dll and the following code:
[Test]
public void MockMessageBoxShow()
{
MockManager.Init();
Mock mbMock = MockManager.Mock(typeof(MessageBox));
mbMock.ExpectAndReturn("Show", DialogResult.OK);
MyCoolMethod("Here we go again.");
// Ensure that all expectations were met.
MockManager.Verify();
}
And with just that little code, just 4 lines dedicated to the mock, 2 of which should be refactored to Setup and TearDown methods, we can mock a static method.
Not cool enough for you? Ok, fine.
Mocking Events
So you have something which expects an object to return certain events. This example does require a professional license of TypeMock, it will not work under the Community Edition, but if you need this functionality then really pay the nice folks their money.
public class GUI
{
public string LovingCSharp { get; set; }
public void Initialize()
{
this.LovingCSharp = string.Empty;
Button button = new Button();
button.Click += new EventHandler(button_Click);
}
private void button_Click(object sender, EventArgs e)
{
this.LovingCSharp += "LOVE!";
}
}
Now let's mock this up, call that event three times, and assert that our property is set correctly.
[Test]
public void MockFormWithEvents()
{
MockManager.Init();
// Mock button so that we can...
Mock btnMock = MockManager.MockAll(typeof(Button));
// Handle all calls to add an event handler.
MockedEvent evntMock = btnMock.ExpectAddEventAlways("Click");
GUI frm = new GUI();
frm.Initialize();
evntMock.Fire(this, EventArgs.Empty);
evntMock.Fire(this, EventArgs.Empty);
evntMock.Fire(this, EventArgs.Empty);
Assert.AreEqual("LOVE!LOVE!LOVE!", frm.LovingCSharp);
// Ensure that all expectations were met.
MockManager.Verify();
}
}
Summary
These are just two examples, and don't even delve into the whole "Natural Mocks" portion of TypeMock. Do yourself a favor, download the evaluation, they'll give you 30 days of all the features (which you can make any individual 30 days you'd like BTW) and ask yourself why you're jumping through all those hoops just to be able to mock dependencies. With this project, you don't have to create dependency injection constructors just to make your classes testable.