[Test]
public void NonTestThreadException()
{
    Thread thread = new Thread(obj => { throw new Exception("Oops..."); });
    thread.Start();
    thread.Join();
}

If an exception isn’t raised on the test thread, the test passes – Oops!

The problem lies in the fact that the ReSharper test runner is configured to behave in the same way as .Net 1.0 and 1.1 apps where unhandled exceptions on non-main threads were swallowed. The situation improves from .Net 2.0 where all unhandled exceptions flatten the process. However, Microsoft had to allow existing .Net 1.0 and 1.1 apps the option of behaving as before on new .Net frameworks. They introduced the app.config setting: legacyUnhandledExceptionPolicy.

The ReSharper test runner is configured by default to use the .Net 1.0 and 1.1 policy, so if there is an unhandled non-test thread exception it does not bubble up and cause the test to fail – the test passes, and we get a false positive instead.

If unhandled exceptions on non-test threads should fail tests, the app.config for the ReSharper test runner has to be updated.

Configuring the test runner to fail on unhandled thread exceptions

1. Firstly find out which test runner executable is actually being used. Run a test in debug mode and look in the Visual Studio output window:

2. Locate the executable’s app.config file, e.g.:

C:\Program Files\JetBrains\ReSharper\v5.0\Bin\JetBrains.ReSharper.TaskRunner.CLR4.MSIL.exe.config

3. Turn the legacy unhandled exception policy off by editing legacyUnhandledExceptionPolicy:

<legacyUnhandledExceptionPolicy enabled="0" />

4. Now multi-threaded tests fail as expected when they raise exceptions on non-test threads:

Buyer beware…

There is a caveat to this. Exceptions on non-test threads will now flattened the test runner and test suite execution will be halted when they happen. This is in contrast to normal test runs where failed tests are marked as failed, and the test runner continues. A pain – annoying? Maybe, but failed multi-threaded tests should be a pain and fixed ASAP. Of course, if they’re not your tests, you can always delete them from the test runner session - move along, nothing to see here, dum-de-dum-de-dum…

This article:

• Assumes your dev team uses the excellent refactoring and all-round code goodness tool that is ReSharper. If you’re not familiar, then please do check it out. It really is very good…
• Describes how to get ReSharper settings automatically propagated around the team.
• Does not discuss coding standards. That’s up to your team to argue bitterly come to an amicable agreement about.

Whilst ReSharper is not a panacea for coding standards, it is very effective for defining rules such as:

• Naming standards: Private instance variables should be named like “_camelCase”.
• Code formatting: Braces should appear on the next line after a statement.
• Language usage: Warn on redundant use of the “.this” qualifier.
• Many Many other settings…

There are a large number of settings that can be configured in ReSharper, and then automatically applied using ReSharper’s excellent Code Cleanup feature, or used to analyze source code to find misdemeanours. Bind Code Cleanup to a keyboard shortcut, and a lot of issues such as formatting and redundant code can be taken care of in an instant. With a little bit of investment (we spent a couple of hours), standards can be configured, and more importantly they can be automatically propagated around the development team through source control.

These are the steps we went through to set up ReSharper:

1. Configuring coding standards.
2. Automating code cleanup.
3. Fine tuning.
4. Sharing ReSharper settings with the team.
5. Sorting the existing codebase out.

Configuring coding standards

First of all a set of coding standards has to be agreed on. Whilst these may grow and be refined over time, getting the bulk of them agreed and configured up-front is the most productive way of doing it.

What we did:

• Got the big points-of-difference discussed and agreed upon e.g. should we use the ‘var’ and ‘this’ keywords? These topics should come easily to most teams, but reaching agreement and compromise is often another matter…
• Got the team together and loaded up our Visual Studio solution. We used a single machine for the initial stages so we could see how settings affected our code.
• Went through ReSharper settings (e.g. Inspection Severities and Formatting Style) changing them until they matched the agreed coding standards.
• Ensured agreed standards were enforced in ReSharper through code formatting rules and displaying warnings (“ReSharper Amber”) for non-compliance.

Coding standards are now configured in ReSharper. If a code file doesn’t get the ReSharper green light, then it isn’t following the standards.

Having ReSharper give amber and red lights for code that fails rules is all well and good, but can ReSharper help us to automate any of this at all? Yes, with ReSharper’s Code Cleanup functionality.

Automating code cleanup

One of the great features in ReSharper is Code Cleanup. This allows code formatting rules, and a selection of code re-writing rules to be automated on a: single file, folder, project, solution, or a mixture of these. It’s really quite flexible.

ReSharper ships with a couple of code cleanup profiles, but a custom profile can be more easily shared amongst the team. Custom profiles can be created in ReSharper options. Add a new code cleanup profile, and set “Profile to use with silent cleanup” to it, as below:

The above screenshot shows the code cleanup profile we use here at GojiSoft. Amongst other things it will remove redundant code (basically anything that is configured in ReSharper as “Redundant”) and automatically apply code formatting rules. Who wants to go through code manually removing unused using statements, namespace qualifiers and other general crud – exactly - use Code Cleanup instead.

Setting “Profile to use with silent cleanup” to your new custom profile means that a ReSharper keyboard shortcut will invoke it and clean up your code automatically. Great, but also very dangerous. Depending on what the context is at the time, it can either clean up your current file or start to clean up your whole project or solution!

We removed the global ReSharper code cleanup shortcut, and replaced it with the Visual Studio shortcut “Format Document Ctrl K, Ctrl D”. This way it’s easy to format a *single* file as you go along. This shortcut can be set up in Visual Studio options:

Tools –> Options –> Environment –> Keyboard

Remove ReSharper global “code cleanup” shortcut

Replace Visual Studio “document format” shortcut

Make sure that the “Use shortcut in” drop-down has “Text Editor” set as the context. This reins code cleanup to the text editor, and prevents any more of its megalomaniacal tendencies to cleanup every file in your solution…

Fine tuning

Ok, so now a fair amount of time has been spent setting up ReSharper, but will automated code cleanup act on our files just the way we like it? It’s time to fine tune those settings.

• Select a bunch of files in solution explorer, right-click and select “Cleanup code…”.
• Use your source control client\favourite diffing tool to see what changes have been made.
• If you’re not happy with the results of automated code cleanup, revisit the ReSharper settings.
• Rinse and repeat until happy.

We now have ReSharper and code cleanup set up just the way we want it, but only on a single machine. How do we go about automatically sharing these settings with the rest of the team?

Sharing ReSharper settings with the team

The built-in support for sharing ReSharper settings is a little patchy, and can’t really be done completely without having to go through a manual settings export/import loop. Getting the whole team in sync with a manual solution isn’t really going to work very well in the long run.

Fortunately ReSharper has plugin support, and ReSharper Settings Manager comes to the rescue. This plugin allows all ReSharper settings to be saved to a single file which can be placed under source control. The plugin will automatically update ReSharper settings if an updated settings file is detected e.g. when an updated settings file is gotten through source control.

• Download and install ReSharper Settings Manager.
• Open the Visual Studio solution on the machine used to set up the coding standards rules.
• Open ReSharper options and configure ReSharper Settings Manager to use a single configuration file per solution:

• Click OK, to close the ReSharper options dialog.
• To verify that a shared settings file is being used, open the settings manager dialog from the Visual Studio menu:

ReSharper –> Tools –> Manage Settings…

• Select the shared settings for your solution from the “Manage Settings” dialog and click Save.
• You should now have a shiny new shared ReSharper settings file in the root of your solution e.g. “MySolution.R#Settings”. This file contains all of your ReSharper settings.
• Add the new settings file to source control.
• Get everyone on the team to install the ReSharper Settings Manager and get latest from source control to get the shared configuration file.
• Settings will now be automatically propagated around the team.
• Spread the word about automated code cleanup and setting up the shortcut.
• Everyone must now “Ctrl K, Ctrl D” and make sure files are ReSharper green before checking into source control. Failure to do so will result in having an arm ripped off and being beaten around the head with the soggy end.

NB When you want to change the shared ReSharper settings: first change the settings, then open the “Manage Settings” dialog (ReSharper –> Tools –> Manage Settings…), select the shared settings file and click Save. The changes can then be committed to source control for sharing with the rest of the team.

Sorting the existing codebase out

This step is optional, but you may wish to sort out the existing code base to make sure it meets the coding standards. The ReSharper feature “Find Code Issues” can be used from solution explorer to find code files where ReSharper rules have failed.  We used divide and conquer to work through folders in our projects, and fixed up all the warnings. If you have a team member with a conspicuously tidy desk with nicely lined up pencils, they may even enjoy doing this task all on their own…

• Part 1 Unit testing event sequences.
• Part 2 Developing an event monitor to test an object’s events.
• Part 3 Using Reflection and MSIL (Intermediate Language) to implement a generic event monitor.
• Part 4 Reflection and MSIL code for dynamic event subscription in detail.
• Conclusion Using the EventMonitor to write [Test]s.

Download Source Code

Conclusion

In Part 1 of this series we saw some of the challenges of writing event unit tests. The challenges mainly revolved around writing lots of repetitive boilerplate code, e.g.:

[Test]
public void EventSequenceTest()
{
    bool eventARaised, eventBRaised;

    eventARaised = eventBRaised = false;

    EventPublisher publisher = new EventPublisher();

    publisher.EventA += delegate { eventARaised = true; };
    publisher.EventB += delegate { eventBRaised = true; };

    //Do some stuff to the state of publisher.
    publisher.RaiseA();
    Assert.IsTrue(eventARaised, "Event A raised.");

    //Do some stuff to the state of publisher.
    publisher.RaiseB();    
    Assert.IsTrue(eventBRaised, "Event B raised.");
}

To add to the mix we saw slight variations with INotifyPropertyChanged events, and further complications with asynchronous events. This all starts getting repetitive and messy when you’ve got lots of tests to write.

In parts 2-4, we went over the gory details of implementing an event monitor which could test the events of any object, and so be used to write unit tests more easily.

So how exactly can the event monitor be used to write unit tests?

EventMonitor.Assert

The EventMonitor class has two static methods:

Assert(Action test, object publisher, IEnumerable<string> expectedSequence)

Assert(Action test, object publisher, IEnumerable<string> expectedSequence, int timeoutMS)

Where:

• test Code which manipulates the state of the test object and causes events to be raised.
• publisher The test object - any object that publishes events.
• expectedSequence A list of event names in the order they are expected to be raised.
• timeoutMS For asynchronous events, the maximum amount of time to wait for each event.

The following show examples of using the EventMonitor with: synchronous, asynchronous and INotifyPropertyChanged events. The event monitor can be used to test an object that has a mixture of these events types.

Synchronous

[Test]
public void EventTest()
{
    var publisher = new EventPublisher();

    Action test = () => { publisher.RaiseA(); publisher.RaiseB(); };

    var expectedSequence = new[] { "EventA", "EventB" };

    EventMonitor.Assert(test, publisher, expectedSequence);
}

Asynchronous

Pretty much the same as testing synchronous events, but with the edition of specifying a timeout value.

[Test]
public void EventTest()
{
    var publisher = new AsyncEventPublisher();

    Action test = () => { publisher.RaiseA(); publisher.RaiseB(); };

    var expectedSequence = new[] { "EventA", "EventB" };

    EventMonitor.Assert(test, publisher, expectedSequence, TimeoutMS);
}

INotifyPropertyChanged

For events that are published via an INotifyPropertyChanged implementation, the event name should be the name of the associated property.

[Test]
public void EventTest()
{
    var publisher = new PropertyChangedEventPublisher();

    Action test = () => { publisher.X = 1; publisher.Y = 2; };

    var expectedSequence = new[] { "X", "Y" };

    EventMonitor.Assert(test, publisher, expectedSequence);
}

Download Source Code

• Part 1 Unit testing event sequences.
• Part 2 Developing an event monitor to test an object’s events.
• Part 3 Using Reflection and MSIL (Intermediate Language) to implement a generic event monitor.
• Part 4 Reflection and MSIL code for dynamic event subscription in detail.
• Conclusion Using the EventMonitor to write [Test]s.

Download Source Code

Part 4

In Part 3 of this series we saw how we could use the DynamicEvent class to create event proxies to allow our event monitor to dynamically subscribe to any type’s events. In this last part of the series we describe the DynamicEvent code in detail showing how Reflection and IL are used to create an event handler proxy for implementing dynamic event subscription.

Dynamic event proxy pattern.

The DynamicEvent Class

Subscribing events dynamically is straightforward using DynamicEvent, but the following steps detail what's going on under the hood...

EventPublisher publisher = new EventPublisher();

foreach (EventInfo eventInfo in publisher.GetType().GetEvents())
{
    DynamicEvent.Subscribe(eventInfo, publisher, (sender, e, eventName) =>
    {
        Console.WriteLine("Event raised: " + eventName);
    });
}

1. Create the event proxy.
2. Create a dynamic method.
3. Inject the event name and call the event handler.
4. Wrapping it all up.

1. Create The Event Proxy

Firstly, the creation of the event proxy is orchestrated when calling CreateProxyEventHandler.

public delegate void ProxyEventHandler(object sender, EventArgs e, string eventName);

//Useful if we need a reference to the delegate for unscribing an event.
public static Delegate CreateProxyEventHandler(
    EventInfo eventInfo, object eventPublisher, ProxyEventHandler handler)
{
    Type eventType = eventInfo.EventHandlerType;
    bool isStatic = handler.Method.IsStatic;
    Type owner = isStatic ? handler.GetType() : handler.Target.GetType();
    string eventName = eventInfo.Name;

    //Step 2 - Create a dynamic method
    DynamicMethod proxyMethod = CreateDynamicMethod(eventType, eventName, proxyOwner);

    //Step 3 - Inject the event name and call to our event handler
    EmitCode(proxyMethod, isStatic, eventName, handler);

    //Step 4 - Wrap the whole thing up in a delegate
    Delegate proxyHandler = proxyMethod.CreateDelegate(eventType, handler.Target);

    return proxyHandler;
}

//Directly subscribe an event handler.
public static void Subscribe(
    EventInfo eventInfo, object eventPublisher, ProxyEventHandler eventHandler)
{
    Delegate proxyEventHandler = CreateProxyEventHandler(
        eventInfo, eventPublisher, eventHandler);

    eventInfo.GetAddMethod().Invoke(eventPublisher, new[] { proxyEventHandler });
}

2. Create a Dynamic Method

Our event proxy is two-sided. Side 1 is called by our event, and side 2 calls into our event handler. For the event side, we must have a method whose signature exactly matches that of the event. As we are dynamically discovering events at runtime, we do not have a matching method in our code, so how do we conjure up a method that has the same signature as our event? We use a dynamic method*.

In preparation for creating our dynamic method, we use reflection to get matching information about the signature of the target event. Having prepared our signature information, we construct our dynamic method. We now have a dynamic method with the same signature as our event.

That’s side 1 of our proxy sorted.

private static DynamicMethod CreateDynamicMethod(
    Type eventType, bool isStatic, string eventName, Type owner)
{
    const includePrivate = true;

    string proxyName = ("Generated proxy for event: " + eventName + ".");
    Type returnType = typeof(void);

    List<type> eventParameterTypes = new List<type>();

    ParameterInfo[] eventParameters = eventType.GetMethod("Invoke").GetParameters();

    eventParameterTypes.Add(proxyOwner);

    eventParameterTypes.AddRange(eventParameters.Select(x => x.ParameterType));

    Type[] parameters = eventParameterTypes.ToArray();

    DynamicMethod proxyMethod = new DynamicMethod(
        proxyName, returnType, parameters, proxyOwner, includePrivate);

    return proxyMethod;
}

* Dynamic methods are created at runtime and provide a shell into which we can emit custom code using IL. Dynamic methods can be wrapped in a delegate and called by any other code – just like a regular delegate. This allows parts of a program to be written whilst the application is actually running – self-modifying code.

3. Inject The Event Name and Call The Event Handler

Now we tackle side 2 of the proxy: the call to our event handler. This is accomplished using IL as we have to generate custom code at runtime.

The IL code sets the call stack up with the arguments to our event handler* (matching the signature of ProxyEventHandler), and then instructs the runtime to call it. Most importantly it is the device used to handle the injection of our event name so that our tests can do their asserting.

The two sides of the event proxy are now completed.

private static void EmitCode(DynamicMethod proxyMethod, bool isStatic, string eventName, ProxyEventHandler handler)
{
    ILGenerator il = proxyMethod.GetILGenerator();

    if (!isStatic)
    {
        il.Emit(OpCodes.Ldarg_0);           //target object for non-static calls.
    }

    il.Emit(OpCodes.Ldarg_1);               //arg0 - sender
    il.Emit(OpCodes.Ldarg_2);               //arg1 - eventArgs
    il.Emit(OpCodes.Ldstr, eventName);      //arg2 - *injected event name*
    il.Emit(OpCodes.Call, handler.Method);  //call proxy event handler
    il.Emit(OpCodes.Ret);
}

* Preparing the arguments for the call stack takes into consideration whether the event subscriber is a static or instance method. All calls to instance methods must have an argument at the first position in the call stack that holds a reference to the instance being called. In a nutshell, the instance reference is passed along by the runtime to the code being executed so it knows what “this” is (static methods do not have a concept of “this”). This is managed by the runtime internally and not exposed at a high level e.g. when programming in C#.

Step 4 - Wrapping It All Up

Now that we have created the dynamic method and emitted our IL code into it, we create a delegate from it. This delegate can be subscribed to an event using reflection.

Delegate proxyHandler = proxyMethod.CreateDelegate(eventType, handler.Target);

eventInfo.GetAddMethod().Invoke(eventPublisher, new[] { proxyHandler });

The signature of the delegate matches the signature of our target event, whilst the arguments pushed onto the stack in our IL match the signature of our test method – the proxy event handler. This combination gives us a proxy that bridges an arbitrary event and our common event handler (see diagram). The injection of the event name into our IL gives us the information about which event has been raised and so allows us to do our testing.

Conclusion

Now we’ve gone over the gory details, we describe how to use the EventMonitor to write unit tests:

Event Sequence Unit Testing – Conclusion

• Part 1 Unit testing event sequences.
• Part 2 Developing an event monitor to test an object’s events.
• Part 3 Using Reflection and MSIL (Intermediate Language) to implement a generic event monitor.
• Part 4 Reflection and MSIL code for dynamic event subscription in detail.
• Conclusion Using the EventMonitor to write [Test]s.

Download Source Code

Part 3

In Part 2 of this series we saw how an event monitor (a test harness) could test event firing sequences for a specific type. This removed repetitive boilerplate code from unit tests and allowed the test specifics to be concentrated on. Great, but we were stuck with strong coupling between the event monitor and the specific event publishing type. What we wanted was a way of generalizing the event monitor so that it could be re-usable across different types without having to maintain convoluted inheritance schemes. We wanted something that would just work.

To generalize the pattern, hard-coding of event subscriptions in the event monitor needs to be removed. Instead, we need to dynamically subscribe a standard event handler to all of a type’s events and also need to know which event has been raised (via the event’s name). To accomplish this a combination of Reflection and IL was used.

The key steps in implementing dynamic event subscription in the event monitor were:

1. Discover all the events of a type.
2. Create a proxy event handler for each discovered event which proxies to the real event handler.
3. Allow the injection of an event name into the proxy call for asserting event firing in tests.
4. Wrap the whole thing up in a delegate that can be subscribed to an event, and which points to our real event handler.

The above steps give us a dynamic proxy that we can use in our event monitor to glue a target type’s event to our real event handler:

Dynamic event proxy pattern as used in the EventMonitor class.

The dynamic event proxy gives us an interface that is compatible with the event we wish to subscribe to, and an interface that is compatible with the real event handler in our event monitor. The interfaces are compatible, plus we have injected the event’s name.

Below we can see how the dynamic event subscription code now looks in EventMonitor, rather than the hard-coded subscription we had in Part 2. Straightforward Reflection is used to discover event information, and the DynamicEvent class (discussed in Part 4) is used to create a dynamic event proxy. Finally, the event proxy is subscribed to the event using reflection.

private void SubscribeToEvents() 
{ 
    //Use reflection to get all the events in the event publisher 
    foreach (EventInfo eventInfo in _eventPublisher.GetType().GetEvents()) 
    { 
        //Create a proxy event handler for the event 
        Delegate proxyEventHandler = DynamicEvent.CreateProxyEventHandler( 
            eventInfo, _eventPublisher, EventHandler); 

        //Use reflection to subscribe our proxy event handler 
        eventInfo.GetAddMethod().Invoke(_eventPublisher, new[] { proxyEventHandler }); 
    } 
} 

private void EventHandler(object sender, EventArgs e, string eventName) 
{ 
    //The event has been raised, and we have the event name. 
    //Do some test asserting... 
}

Excerpt from EventMonitor.cs

We can now test asynchronous event patterns for arbitrary event publishing types with the event monitor as follows:

Action test = () => { /*Code to change publisher twice, then delete it. */ } }; 

var eventSequence = new[] { "Changed", "Changed", "Deleted" }; 

EventMonitor.Assert(test, publisher, eventSequence, TimeoutMS);

Reflection and IL code used to create the dynamic event proxy in class DynamicEvent is discussed in detail in the last part of this series:

Event Sequence Unit Testing – Part 4

• Part 1 Unit testing event sequences.
• Part 2 Developing an event monitor to test an object’s events.
• Part 3 Using Reflection and MSIL (Intermediate Language) to implement a generic event monitor.
• Part 4 Reflection and MSIL code for dynamic event subscription in detail.
• Conclusion Using the EventMonitor to write [Test]s.

Download Source Code

Part 2

In Part 1 of this series we explored unit testing event sequences, both synchronous and asynchronous. We saw that it involved writing a lot of repetitive boilerplate test code:

using (FileWatcher fileWatcher = new FileWatcher(fileToMonitor))
using (AutoResetEvent changedEvent = new AutoResetEvent(false))
using (AutoResetEvent renamedEvent = new AutoResetEvent(false))
using (AutoResetEvent deletedEvent = new AutoResetEvent(false))
{
    fileWatcher.Changed += delegate { changedEvent.Set(); };
    fileWatcher.Renamed += delegate { renamedEvent.Set(); };
    fileWatcher.Deleted += delegate { deletedEvent.Set(); };

    //Do some stuff to the file...
    
    //  * Change the file.
    Synchronization.WaitWithTimeout(changedEvent, TimeoutMS, "Changed event failed.");

    //  * Rename the file.
    Synchronization.WaitWithTimeout(renamedEvent, TimeoutMS, "Renamed event failed.");

    //  * Delete the file.
    Synchronization.WaitWithTimeout(deletedEvent, TimeoutMS, "Deleted event failed.");
}

When you’re writing a lot of unit tests, this really starts to grind. What we are really interested in when writing these tests is:

• “Do some stuff to the state of x.”
• Defining an expected sequence of events.
• Having something else take care of running and asserting the event sequence.

To cut down on repetitive code and give flexibility for implementing features such as reporting test failure with helpful diagnostic messages, Frederik began writing an event monitoring test harness for his FileWatcher component. The event monitor handled event hooking and synchronization, plus asserting the expected event sequence. This enabled developing unit tests that concentrated on “Do some stuff to the state of x.”. Unit testing with an event monitor looks like this:

Action action = () => { /* Code to create a file, then change it. */ }; 

var expectedSequence = new List<EventName> { EventName.Created, EventName.Changed }; 

using (var monitor = new EventMonitor(file, TimeoutMS, expectedSequence)) 
{ 
    monitor.Start(action); 
}

In the unit test pattern above we can see the code that makes the state changes is defined in: action, and the expected event sequence is defined in: expectedSequence. These are used in conjunction with the EventMonitor which:

1. Constructs an instance of the component to be tested: a FileWatcher.
2. Subscribes to its events so that it is notified when events are raised.
3. Executes the state changing code (defined in: action).
4. Asserts that the raised event sequence (subscribed to in 2) is adhered to.
5. Prints a helpful diagnostic message if the test fails, e.g.

     GojiSoft.TestFramework.Events.EventMonitoringException: Out of order execution at event 2.

        Expected sequence  - (start) (1)Changed (2)Renamed (3)Deleted

        Actual sequence      - (start) (1)Changed (2)Changed.

As I was also writing asynchronous event raising components, and had the same sort of boilerplate unit test code, I liked the look of this pattern a lot. However, the implementation required writing a specialized monitor for each component as event subscriptions had to be hard-coded within the monitor:

private void AssignEvents() 
{ 
    _fileWatcher.Changed += ((sender, args) => 
    { 
        //Handle event... 
    }); 

    _fileWatcher.Deleted += ((sender, args) => 
    { 
        //Handle event... 
    }); 

    //etc, etc… 
}

Code excerpt from EventMonitor.cs

As we can see from the above code snippet, the EventMonitor directly subscribes to the FileWatcher component events – it is hard-coded. I liked the overall technique and wanted to use it with my components, so I looked at generalizing it to provide an event monitor that could monitor the events of any type.

Generalizing the event monitor required the use of Reflection and IL (Intermediate Language). This is the subject of the next part in the series:

Event Sequence Unit Testing – Part 3

[Test] 
public void TestEventRaisingSequence() 
{ 
      var myClass = new MyEventRaisingClass(); 
 
      Action test = () => { myClass.RaiseA(); myClass.RaiseB(); }; 

      var expectedSequence = new[] { "EventA", "EventB" }; 

      EventMonitor.Assert(test, myClass, expectedSequence); 
} 

The framework handles synchronous & asynchronous event raising, as well as property change notification (INotifyPropertyChanged).

Download Source Code – Documentation

This four part article describes how the framework works and how it evolved from boilerplate unit tests to a pain-free framework that generates IL on the fly.

• Part 1 Unit testing event sequences.
• Part 2 Developing an event monitor to test an object’s events.
• Part 3 Using Reflection and MSIL (Intermediate Language) to implement a generic event monitor.
• Part 4 Reflection and MSIL code for dynamic event subscription in detail.
• Conclusion Using the EventMonitor to write [Test]s.

Part 1

An aspect of developing components that raise events is writing unit tests to codify expected event sequences e.g. when I change state s1 and then s2, I expect event e1 then event e2 to be raised. This style of testing helps to codify event firing expectations and then to keep those expectations locked down as the system evolves - classic unit testing goals.

Given a shortened example of an event publishing type EventPublisher:

public class EventPublisher
{
    public event EventHandler EventA, EventB;

    public void RaiseA()
    {
        EventA(this, EventArgs.Empty);
    }

    public void RaiseB()
    {
        EventB(this, EventArgs.Empty);
    }
}

We can write unit tests against it as follows:

[Test]
public void EventSequenceTest()
{
    bool eventARaised, eventBRaised;

    eventARaised = eventBRaised = false;

    EventPublisher publisher = new EventPublisher();

    publisher.EventA += delegate { eventARaised = true; };
    publisher.EventB += delegate { eventBRaised = true; };

    //Do some stuff to the state of publisher.
    publisher.RaiseA();
    Assert.IsTrue(eventARaised, "Event A raised.");

    //Do some stuff to the state of publisher.
    publisher.RaiseB();    
    Assert.IsTrue(eventBRaised, "Event B raised.");
}

Here we test that when we change state A followed by state B, event A and then event B is raised.

The implementation is a little different when we have a type that implements the INotifyPropertyChanged pattern:

public class PropertyChangedEventPublisher : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    private int a, b;

    public int A
    {        
        set
        {
            this.a = value;
            this.PropertyChanged(this, new PropertyChangedEventArgs("A"));
        }
    }

    public int B
    {
        set
        {
            this.b = value;
            this.PropertyChanged(this, new PropertyChangedEventArgs("B"));
        }
    }
}

We can write unit tests against it as follows:

[Test]
public void EventSequenceTest()
{
    bool eventARaised, eventBRaised;

    eventARaised = eventBRaised = false;

    PropertyChangedEventPublisher publisher = new PropertyChangedEventPublisher();

    publisher.PropertyChanged += (sender, e) => 
    {
        if (e.PropertyName == "A")
        {
            eventARaised = true;
        }
        else if (e.PropertyName == "B")
        {
            eventBRaised = true;
        }
    };

    //Do some stuff to the state of publisher.
    publisher.A = 1;
    Assert.IsTrue(eventARaised, "Event A raised.");

    //Do some stuff to the state of publisher.
    publisher.B = 2;
    Assert.IsTrue(eventBRaised, "Event B raised.");
}

Matters are further complicated when we have a type that raises events asynchronously i.e. on multiple threads:

public class AsyncEventPublisher
{
    public event EventHandler EventA, EventB;

    public void RaiseA()
    {
        ThreadPool.QueueUserWorkItem(delegate { EventA(this, EventArgs.Empty); });
    }

    public void RaiseB()
    {
        ThreadPool.QueueUserWorkItem(delegate { EventB(this, EventArgs.Empty); });
    }
}

Our previous unit testing pattern no longer works as the test starts asserting the event raising conditions before our threads have raised the events. For the same test, but with asynchronous events, we need to introduce thread synchronization:

[Test]
public void AsyncEventSequenceTest()
{
    AsyncEventPublisher publisher = new AsyncEventPublisher();

    using (AutoResetEvent eventA = new AutoResetEvent(false))
    using (AutoResetEvent eventB = new AutoResetEvent(false))
    {
        publisher.EventA += delegate { eventA.Set(); };
        publisher.EventB += delegate { eventB.Set(); };

        //Do some stuff to the state of publisher.
        publisher.RaiseA();
        AssertEvent(eventA, 1000, "Event A failed.");

        //Do some stuff to the state of publisher.
        publisher.RaiseB();
        AssertEvent(eventB, 1000, "Event B failed.");
    }
}

private static void AssertEvent(WaitHandle waitHandle, int timeoutMS, string message)
{
    if (!waitHandle.WaitOne(timeoutMS))
    {
        message += " Timed out after waiting " + timeoutMS + "ms.";
        throw new TimeoutException(message);
    }
}

In this variation of the test we use AutoResetEvents to synchronize our test thread with our event threads, thus ensuring that we wait for the event threads to execute. If events are not raised, then we timeout and an exception fails the test.

My partner in dev Frederik was developing a file system monitoring component and found that we were both writing this sort of boilerplate unit testing code again and again. To simplify unit testing he started developing an event monitoring test harness which could be used to generalize event sequence testing for his component and reduce the boilerplate coding.

This series of posts will describe how a generic event monitor pattern can be used to allow much more straightforward unit tests of synchronous, asynchronous and INotifyPropertyChanged style events:

[Test]
public void EventTest()
{
    var publisher = new MyEventPublisher();

    Action test = () => { publisher.RaiseA(); publisher.RaiseB(); };

    var expectedSequence = new[] { "EventA", "EventB" };

    EventMonitor.Assert(test, publisher, expectedSequence);
}

Or:

[Test]
public void EventTest()
{
    var publisher = new MyPropertyChangedEventPublisher();

    Action test = () => { publisher.X = 1; publisher.Y = 2; };

    var expectedSequence = new[] { "X", "Y" };

    EventMonitor.Assert(test, publisher, expectedSequence);
}

Event Sequence Unit Testing – Part 2