Testing VB6 with NUnit

We at Improving are huge fans of test-driven development (TDD).  I just started a short project for a client who requires the development (for very valid reasons) to be done in VB6.  I did a little research around TDD in VB6 and found vbUnit as well as some other tools.  However, months ago I'd heard about the rare and mysterious practice of unit testing VB6 code from NUnit.  Only, I couldn't find a single reference to it with Google.  So, here's what I learned from one of my wife's coworkers....

1. Create your VB6 code in an ActiveX DLL project (e.g. Project).  Add and develop classes as normal in this project.

2. Use menu item File|Make DLL to copile the DLL (e.g. Project.dll) and automatically register it for use.

3. In Microsoft Visual Studio .Net (or 2003), create a DLL solution and add references to the .Net assembly NUnit.Framework and the COM library produced by VB6 (e.g. Project).  VS.Net auto-gens a COM wrapper for you (e.g. Interop.Project.dll) in the bin directory.

4. Write .Net test cases to invoke member functions of classes in Project. You can make a using Project; statement if desired.  Build your DLL as normal.

5. Execute tests by FIRST running the ActiveX DLL from the VB6 environment.  This puts VB6 in debug mode.  Set a breakpoint somewhere to prove that it's working.  SECOND: launch NUnit, open your .Net assembly, and run some tests. 

NOTE: If you don't run the VB DLL first, NUnit will report a System.Runtime.InteropServices.COMException. 

Of course, once you're up and running, you'll want to change the order of these steps so you're actually writing your tests first. ;)

I hope to have NO other words of wisdom about hard to find answers to VB6 development questions from this project.  But, it is worth mentioning that www.connectionstrings.com had the answer I needed for connecting to a password-protected database with ADO.

Comments

[Fiach Reid]

Any ideas on how to apply this technique to VB6 .EXE's rather than DLL's?

[Todd Girvin]

No, man. Sorry I can't help you there. I'm not doing VB6 dev anymore so I don't even have an environment to experiment. Testing is one motivation for separating out "application services", or services provided by an application into a DLL and making your EXE just the presentation layer with your forms and such. Of course, the other reason is just good layering practice to separate concerns between presentation, app service, domain logic, and persistence.

[alex]

Just use simplyvbunit to use VB6 unit testing (exes as well as dlls) and avoid paying fees for software. http://simplyvbunit.sourceforge.net/

[jimbo]

hi there. is there a way that you can test the DLL's private methods? thanks.

[Todd Girvin]

I don't think you can access the private methods of a DLL because they aren't listed as entry points. That's an issue in .NET, too, as we sometimes have to make methods public just to get at them for testing. That being said, I bet someone has devised a crafty way around it using attribution and lookup tables or something. If you could collect the function pointer in one place, a test tool to jump right to the functions being tested. But accessing private members in Windows DLLs would normally be a potential security hole.