Tips On Using Vb Unit

Some tips on using VbUnitThree, most of which also apply to earlier versions.

On the Yahoo Refactoring mailing list TobinHarris asked some questions about how to use vbUnit3 (VbUnitThree) effectively. My response grew somewhat detailed, so I posted it here:

I used Bodo's vbUnit2 on my previous project and am now using vbUnit3 (both professional and basic) on my current project (in late 2001). (...and another project in 2002.)

I find it best to have my application code in an ActiveX server, typically a DLL, in one directory, and the test code in another directory. That way I can easily compile the production code and not accidently get test code mixed in. Use "Project -> References" to make the test project "point to" the application project. Create a group file in the test directory that includes both the test project(s) and production project(s); that way you can debug and step through both.

I often have the vbUnit test project as a subdirectory of the application project it tests. Typical organization:

"C:\some\good\place\myAppName" = directory containing "myAppName.vbp" and all production project files included in the release.
"C:\some\good\place\myAppName\Test" = subdirectory of application directory. Contains my vbUnit test project, with all its test fixtures (classes). This is also a good place for a VB "project group" (.vbg) that includes the test project and the application ("..\myAppName.vbp")

-- JeffGrigg

Limitations:

Functions in modules can't be seen from "outside" the ActiveX server. Workaround: Add the module to the vbUnit test project. VB is smart enough (mostly ;-) to realize that both test and application projects are referencing the same file and will prompt you at appropriate times to "share changed contents" with the other project. ("Yes" is normally the right answer.)
Major annoyance: VisualBasic gets confused about relative path names when working on projects in more than one directory. It will add redundant relative paths to all the modules and classes you add. (And sometimes, in a fit of confusion, it may add them to all modules and classes in a project.) I find that I must always edit the project (.vbp) files by hand before checking into source control, whenever I add classes, modules or forms to a project. See VisualBasicProblemsWithRelativePathNames.
Whenever you have a VisualBasic project group that spans multiple directories, you must watch the default directory VB gives you to save new classes/forms/modules, and when compiling: VB likes to track the last directory you used rather than use the directory for the project the file belongs to.

MockObjectsInVb describes a technique widely use in other languages, that is very relevant to VbUnit.

[Inspired by some comments on VbUnitWishList, and some conversation I had with BodoMaass]

You need to do some comparisons and assertions that vbUnit does not support: Comparing objects, comparing file contents, comparing binary strings, comparint Variant variables to ensure that both type and value are equal, or any of many other kinds of comparisons you may wish to do.

Should you try to put the new comparison into vbUnit, or should you write a function in your testing application to do the comparison?

Answer: Write functions and methods in your test project(s). If they prove useful, you'll want to put them in a common file or project, for use across your test projects. If they prove very useful, and seem to be something that people on different projects may find useful, then you might offer them to BodoMaass for inclusion in vbUnit.

Realize that even if BodoMaass does not wish to include your valuable reusable functions in the official release of vbUnit, you could always package your library of reusable functions and publish them independently, for people to use with vbUnit. So don't be discouraged; there's always a way.

Here's an arbitrary data point: On a moderately sized test project I happen to be looking at right now, I have a module ("modDebugReuse") with 243 lines of functions that are used by multiple test fixtures. In this project I have one test suite, 15 test fixtures, 8 mock objects, and 9 additional classes that help support testing - several of which are fairly well reused. -- JeffGrigg

While I may not have time to include and support every addition to vbUnit in the main distribution, I'll be happy to post any add-on on the vbUnit website. -- BodoMaass

Hint Taken. Seriously, that sounds a much better idea than adding too much to VBUnit. -- AndyMorris

Sometimes it's a bit of a fag creating suites that only run one fixture, or your suite takes a while to run and you only want to run one fixture, PutSmallFixtureInWithSuite -- AndyMorris

CategoryTesting