Test Driven in VB 6

OK. Due to severe scheduling restraints (IE I’m 1 month late on this project), I am forced to run test-driven in VB 6.

With the help of vbUnit3 Framework and vbUnit-Free Add-In, the unit testing bit is setup.

VBMock provides a framework for mocking objects in vb 6. This works well. There are two notes here for VBMocking.

1.) Remember that VB 6 does NOT provide true OOP inheritance… IE “Implements” requires you to “overwrite” the super’s routines. This might be as simple as call-forwarding the super’s call, but it must be manually handled. This provides the “out” for Mocking… the mock object can reference directly the target Class.. no Interface is required. Then the MockingClass can properly mock-override the target Class routines.

2.) EXE/DLL arrangement and Modal Forms. Well, here’s the black-belt approach to VB programming. You will probably want to implement a splash-form. This form must exist on the EXE Project. ControlBox off and no Caption gives you a “windowless” splass screen. It will appear in the task tray UNTIL it is minimized. This gives you the opportunity to hand off control to the main form residing in the DLL. UNLESS you are using MDI. MDI cannot exist inside a DLL, so your EXE will contain the MDI. In this case, if you wish to employ a splash or not is up to customer requirements. In the case of no-MDI, the main form referenced from the EXE to the DLL must have an additional routine Init() to allow you to pass the reference of the splash form into the Main form…. this will prevent the Sub Main() from following the code path after the Form.Show() of your splash and then shutting down the application. Your main form must catch Form_Unload can call Unload fSplash_ in order to allow the entire application to properly exit when the main form is closed.



Well, mocking the average form is A-OK, but we don’t have the advantages of .NET Reflection here, so there is no “catching” a call to a modal form or internally handling events when the form is displayed.

The approach :

Create class “ModalForms” (I Resist the name “Dialogs” because sometimes a Modal is not necessarily a dialog but more like a dictatorial command).

Class ModalForms

Public Sub MessageBox() : Wrapper the standard MsgBox call. WHY? You need a way to Mock message boxes to the main application in order to test main-form logic. SOOO, wrappering the MsgBox allows you to send mock responses back to your main-form for TDD logic paths.

Public Sub : Same theory as above.

Oh, and another thing… you’ll notice that you need one more public class “NormalForms” that provides getters to the non-modal form objects. This is because forms are private to the project and must be manually exposed on the DLL interface so that your EXE can get them.

More Later.