verifying an event is called

[Yaron Naveh]

Hi

I'm testing some class A which raises some event E:

class A
{
public event E;
...
}

I want to verify that E is raised with the correct parameters.
I thought of something like this:

var mock = new Mock<EHandler>()
A.E += new EHandler(mock.Object);
mock.Setup(...)

but it seems only an interface can be mocked.
I can create a dummy interface for this - but is there a better way?

Thanks,
Yaron

[Drew Noakes]

I raised the question of support for mocking delegates just a few days ago:

http://groups.google.com/group/moqdisc/browse_thread/thread/a4fd1d6ec5335e51

If that were possible, then you could write code as you suggested.

  var clickHandler = _mock.Create<EventHandler<ClickEventArgs>>();

  button.Click += clickHandler.Object;

  clickHandler.Setup(h => h(button, new ClickEventArgs(MouseButton.Left)));

The signature of the event is defined by the delegate, and it seems to me a bit silly to have to define an interface with a single member just to allow testing of what you are talking about.

Daniel's response to my question was:

> Don't think we'll support this anytime soon (unless we get a patch, as usual :))

Following this response I have some questions.  First, to those who control the philosophy/direction of Moq (and consequently, commits of patches):

- Is this something you just don't have bandwidth for, or does it cut against the grain of where you see Moq heading?  Asked another way, would a patch that supports this be accepted?

Questions for the whole group:

- How many people would like to see support for mocking delegates added?

- Has anyone tried this and hit any barriers?

- Can anyone improve upon the code sample given above?

Drew.

---

From: Yaron Naveh <yaro...@gmail.com>
To: Moq Discussions <moq...@googlegroups.com>
Sent: Sunday, 17 May, 2009 18:32:25
Subject: [Moq] verifying an event is called

[Daniel Cazzulino]

It's about bandwidth. If you submit a patch with a working implementation and corresponding unit tests, I'd be happy to merge it in :)

That said, I fail to see how mocking a delegate is useful at all. Consider the alternative:

ClickEventArgs args = null;
object sender = null;

  button.Click += (s, e) => { sender = s; args = e };

// do the work with the button, that would fire the click event eventually

Assert.AreSame(sender, button);
Assert.AreEqual(MouseButton.Left, args.MouseButton);


This is one of those scenarios where I feel you're taking it too far with the mocking framework. A little bit of state testing in this case is so much cleaner...

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

[Drew Noakes]

> This is one of those scenarios where I feel you're taking it too far with
> the mocking framework. A little bit of state testing in this case is so much
> cleaner...

I guess it depends how far you want to verify the behaviour. In this
case, you may want to verify that the event only fires once, and you
may want to make some guarantees about the arguments passed. I'm only
interested in using a framework if it helps me make my code simpler
and cleaner (and everything Moq does could be done via hand-crafted
mocks). For what I want to achieve in some test scenarios, the
ability to mock delegates would make the code cleaner (see example in
my previous post).

I'll have a look through the code and see about creating a patch.

[Daniel Cazzulino]

> only fires once

Then the sample you sent won't work, unless you specify It.IsAny for both arguments and count the invocations.

I remain unconvinced of the value of such a feature, specially since you don't have to create anything outside your test in order to achieve the same with plain C#. Moq automates things that you'd have had to do manually *outside* the test (i.e. creating a new class, keeping state, etc.), but in this case I don't think you gain much clarity...

Feel free to submit a patch, it would be very much welcomed anyways!

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471