While EnhancingVbUnit, some people discussed VBUnit''''s issues with event processing and proposed some solutions:

----

I'm trying to get started using VBUnit (Bodo's version), and I've tripped over an interesting problem. When you load a VB form from inside a unit test, most of the usual form creation events don't fire. Specificly, only Form_Initialize fires; Form_Load, Form_Resize, Form_Activate, Form_GotFocus, and Form_Paint don't. The form's window appears on the screen just fine (aside, of course, from the fact that control setup code inside the unfired event handlers doesn't get executed).

After poking around through various permutations of my code and trudging through the MSDN, it begins to smell like the problem is that VBUnit tests have to live in an ActiveX DLL. The MSDN contains a few tantalizing hints that some aspects of forms are, ahem, less then functional when inside an ActiveX component. As usual, they don't really explain the problem.

Has anyone else seen this behaviour? Thoughts, comments, workarounds?
-- JohnMaxwell

----

This problem should be fixed by the new TestRunner that comes with vbUnit3 (VbUnitThree), to be found at
 Running Tests     -- http://www.vbunit.org/doc/TestRunner.htm

-- BodoMaass

----

OK, an update to that last.

The MSDN reference was a dead end. The problem appears to be caused by VBUnit; at least, a short test program reveals that form events fire Just Fine inside an ActiveX DLL.

As a further twist, custom events (not related to forms in any way) also don't seem to fire. I've added an event to my data model object, and my test to make sure it fires when I expect it to fails. Again, when I use the object a standlone program (not involving VBUnit), the @*#! thing fires fine. Grrr.
-- JohnMaxwell

----

OK; I finally tracked down the problem (actually, I tracked it down some time ago, but I've been too busy to update the Wiki).

Turns out that if you're unit testing a form, you can't run the VBUnit test results form as a modal form; it grabs all of the events and the form under test won't see them. This actually applies to testing any code that uses events, not just forms... but forms are where it really hurt me.

The solution is simple: Don't show the test results form as a modal form. The boilerplate code in the VBUnit documentation won't work right with the test results form as a non-modal form, though. It puts up the form, and then immediately exits from the Sub Main, taking the form right back down again.

The simplest workaround is to put an infinite loop containg a call to DoEvents right after the call to Run, like this:

	oTestRunner.Run False,True
	While True
		DoEvents
	Wend

This has the nasty side effect that you have to use the debugger to stop the program after running your tests, which gets annoying real fast. I've played with adding a property to the TestRunner class, so that you can exit the loop after the test results form is closed, like so:

	oTestRunner.Run False,True
	While oTestRunner.DialogVisible
		DoEvents
	Wend

This works much better, but leads me to another question: Why bother with being able to run as a modal form in the first place? I think the best solution is to move the While loop inside TestRunner's Run method, and lose the first argument to Run. Opinions?
-- JohnMaxwell

----

Another way of looking at it is that if the test results form is loaded non modal, from the dll and then your runner program ends, the oTestRunner. class is unreferenced so that the dll has no referenced members so it closes all windows and ends. 

If we opened a non modal form in our runner .exe this could keep the runner .exe "up" and therefore the oTestRunner would still be referenced. We would have to make the instance of TestRunner have module scope so that it didn't drop out of scope.

Don't know if this will make any sense to anyone else, I'd try it myself but I don't have VB installed at home. At work VBunit is a bit of a guilty secret as Dev Support like to vet tools before we use them, so I don't want to be seen 'wasting' time on an unapproved tool --AndyMorris

I can't resist to point out that perhaps you should consider changing jobs, judging from your implicit description of the workplace. I thought that since the advent of books like TheMythicalManMonth, PeopleWare etc. these scenarios were extinct. They should be, IMHO. [Dev Support does not really facilitate if it hinders you from doing the best job you can, now is it?]
If you either like/need your job badly, you may opt for some SkunkWorks there.
-- SethHeeren