When we come to write unit tests we stumble upon many different problems with many different parts of our code, because no matter how hard you try, your code is never as simple as the examples around the web. If it’s singletons, static methods, private members that need mocking, or even events that need to be checked.
lately I spent some time writing unit tests and fumbled around with many of this problems. There are many articles around the web telling you the problem is not that you don’t know how to test this parts, it is that it shouldn’t exist in the first place. I really don’t like this answer, saying I shouldn’t write my code this way because there is a better one is a valid argument, but telling me I HAVE to change my code in order for it to work is usually not true. Some places don’t say this but still, most don’t give you a solution.
After this brief intro I will go into saying that I will try in a few different posts to clear up some of the problems in unit testing, mainly the ways to overcome them.
Lets start =]
As the title states, in this post I will show how to unit test events.
What we are going to do here is use an Anonymous delegate in order to catch the event inside our test.
The code: (look afterwards for the explanation and break down)
[TestFixture]
public class SettingsFixture
{
[Test]
public void ChangeSettingFiresSettingsChangedEvent()
{
// success variable
bool success = false;
// new setting
string key = "SomeKey";
string value = "SomeValue";
// set a new instance
SettingsManager settingsManager = new SettingsManager();
// register to the event
settingsManager.SettingsChanged += delegate(object sender,
EventArgs e)
{
// event raise, test successfull
success = true;
};
// update a setting to raise the event
settingsManager.UpdateSetting(key,value);
Assert.True(success);
}
}
So what we have here?
We have a TestFixture with a single Test called:
ChangeSettingFiresSettingsChangedEvent
Change Setting Fires SettingsChanged Event.
First, we setup the success variable which we will commit later as the test’s result.
Second, set up our "new" setting, if we would use a special Type to submit to the UpdateSetting method, ISetting lets say, this will be the place to Mock(Mocking will be discussed in a future post, I will link to it then) it.
Third, setup a new instance of our SettingsManager.
Fourth, register to the SettingsChanged event as we usually will, with one big difference. instead of using a new instance of the right delegate we use an Anonymous delegate, look at the code for the syntax, it is very simple.
Fifth, call UpdateSetting with our "new" setting so the event will be raised.
Sixth, commit the result, hoping that it all went as planned ;].
Seventh, show off to your friends and go home, it’s late! (somewhere in the world…)
Hope it was clear enough.
A nice post about this:
Just to clarify: I am using C#(if you haven’t noticed yet) with NUnit.
See you next time =].
Nadav
