views:

30

answers:

1

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.

+1  A: 

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...

Mark Seemann
Thank you very much for reminding me of the idiom (the OnEvent idiom) I haven't thought of that, though I have encountered this before.RhinoMocks doesn't seem to be able to invoke protected members, but creating my own background worker mock would seem to do the job.I am trying to test whether my object will react correctly to Background worker results, I am not going to even try multithreaded unit testing. Thanks for the warning though.
Tomas Pajonk