Question

I am trying to test how my class reacts on to what happens when the BackgroundWorker fires the RunWorkerCompleted event.

I am using RhinoMocks (if there is another approach I am willing to try it as well) and the code is as follows:

//arrange
var bw1 = MockRepository.GenerateStub<BackgroundWorker>();
Action work1 = () => Thread.Sleep(1);
WorkQueueProcess processInQueue = new WorkQueueProcess(bw1) { Work = work1 };
var tested = new WorkQueue() { processInQueue };

// act
bw1.Raise(
    bw => bw.RunWorkerCompleted += 
        null, 
        bw1, 
        new RunWorkerCompletedEventArgs(null, null, false)
);

// assert
Assert.AreEqual(false, tested.IsBusy);

I am getting an exception that says:

Invalid call, the last call has been
used or no call has been made (make
sure that you are calling a virtual
(C#) / Overridable (VB) method).

What am I doing wrong ? Is it because BackgroundWorker has no virtual methods? I thought I should be able to raise an event regardless, because event are hardly ever virtual.

Answer 1

Only the class that defines an event can raise that event. That is simply how the event system in .NET works.

The Raise method provided by RhinoMocks is intended to be used with interfaces that define events. In that case, any class implementing that interface owns its own event, and thus is able to raise it. That is also true for the run-time emitted types generated by RhinoMocks.

However, when it comes to classes, even sub-types can’t raise events defined by their supertypes, which is why we have the OnEvent coding idiom.

BackgroundWorker does have the OnRunWorkerCompleted method that will raise the event. This method is virtual, so if you can get RhinoMocks to invoke this protected method, you should be able to raise the event.

I’m using Moq, which can’t do that – I can’t remember if RhinoMocks has the ability to invoke protected members.

Otherwise, you can derive a test-specific class from BackgroundWorker and add a public method that invokes OnRunWorkerCompleted.

As a closing remark, however, I would strongly recommend that you don’t try to unit test multithreaded code – along that road lies only pain…