Oct
8
1

Don’t call us we’ll call you

Author Eli Lopian    Category .NET Tests     Tags

Testing how events are hooked up to your system can be tricky, TypeMock.NET makes this easier.

Testing the plumbing

Lets see how we test a class that fires events.

Here is a snippet from a List that fires event whenever an Item is added

public class ListWithChangedEvent : ArrayList
{
    // An event that clients can use to be notified whenever the
    // elements of the list change.
    public event ChangedEventHandler ChangedEvent;

    // Override some of the methods that can change the list;
    // invoke event after each
    public override int Add(object value)
    {
        int i = base.Add(value);
        if (ChangedEvent != null)
        {
            ChangedEvent(this, EventArgs.Empty);
        }
        return i;
    }
}

(10 point to the first to find the Race Condition bug)

To test this class we can test the following scenarios:

  1. No event listeners registered
  2. One event listener register – gets called
  3. Two event listeners registered – gets called

Testing that an event listener gets invoked is a classic interaction based test and mocking frameworks work very well with this.

Here is the second test: 

[Test]
public void TestEventWorks()
{
    // Create a new list.
    ListWithChangedEvent list = new ListWithChangedEvent();

    // Try with one listener
    // add a listener
    list.Changed += new ChangedEventHandler(list_Changed);
    using (RecordExpectations record = RecorderManager.StartRecording())
    {
        // expect to be called when adding to list
        list_Changed(list, EventArgs.Empty);
    }
    // Add item to the list.
    list.Add("item 1");
    // make sure it was called
    MockManager.Verify();
}

// dummy method that is used as a placeholder
void list_Changed(object sender, EventArgs e)
{
    throw new Exception("The method or operation is not implemented.");
}

There is no need to create an object that uses the ListWithChangedEvent to test the list, and with this test we can verify that the event mechanism is working.

Meanwhile at the other side…

At the other end, we have a class that registers to the event and performs some action when the event is called.

Suppose we have a class that registers to the Button.Click event

  

public void Example()
{
   Button button = new Button();
   button.Click += new EventHandler(button_Click);
}

private void button_Click(object sender, EventArgs e)
{
   // Do Somethings here
}

To test that the Example class works correctly when the button is clicked, the Button can be Mocked. It is then possible to make Example believe that the button was clicked (Note this feature requires version 3.6)

[Test]
public void TestThatExampleWorksWhenButtonClicked()
{
    using (RecordExpectations record = RecorderManager.StartRecording())
    {
        // mock next button and the event registration
        Button mockedButton = new Button();
        mockedButton.Click += null;
    }
    // invoke our test method that registers to button.Click
    Example();
    // Fire the event
    RecorderManager.LastMockedEvent.Fire(this, EventArgs.Empty);
    // here we test that Example works correctly
    //...

    MockManager.Verify();
  }

When the LastMockedEvent is Fired the button_Click is invoked, and we can verify that our class handles the event correctly. The heart of this exercise is the ability to mock an event registration and then fire that mocked event

Bookmark and Share

1 Comment to “Don’t call us we’ll call you”

Post comment