Some Visual Basic 6 Tools

We now turn to a discussion of the three Sourcerers mentioned at the beginning of the chapter. These tools—the Assertion Sourcerer, the Metrics Sourcerer, and the Instrumentation Sourcerer—will help you detect and prevent bugs in the programs you write.

Registering the Three Sourcerers

All three Sourcerers we're going to discuss are available in the CHAP06 folder on the companion CD. These Sourcerers are designed as Visual Basic 6 add-ins, running as ActiveX DLLs. To register each Sourcerer in the Microsoft Windows 95/98 or the Microsoft Windows NT system Registry, load each project in turn into the Visual Basic 6 IDE and compile it. One more step is required to use the add-ins: you must inform Visual Basic 6 itself about each add-in. This is done by creating an entry in VBAddin.INI under a section named [Add-Ins32]. This entry takes the form of the project connection class name, for example, VB6Assert.Connect=0 for the Assertion Sourcerer. To perform this automatically for all three Sourcerers, just load, compile, and run the BootStrap project available in the CHAP06 folder on the companion CD. This will add the correct entries in the VBAddin.INI file.

Assert Yourself: The Assertion Sourcerer

Although Debug.Assert fulfills its purpose very well, improvements to it would certainly be welcome. It would be nice if you had the ability to report assertion failures in compiled code as well as source code. Because one of the aims of the Enterprise Edition of Visual Basic 6 is to allow components to be built and then distributed across a network, it is quite likely that others in your organization will want to reference the in-process or out-of-process ActiveX servers that you have built using Visual Basic. Ensuring that assertion failures in compiled Visual Basic 6 programs were reported would be a very useful feature, enabling better testing of shared code libraries and allowing the capture of assertion failures during user acceptance testing. This kind of functionality cannot be implemented using Debug.Assert because these statements are dropped from your compiled program. Additionally, because you cannot drop from object code into Visual Basic's debugger on an assertion failure, you are faced with finding some alternative method of reporting the assertion failures.

Step forward the Assertion Sourcerer. This add-in supplements Debug.Assert with the functionality mentioned above. When you have registered the Sourcerer in the Registry and used the Add-In Manager to reference it, you can select Assertion Sourcerer from the Add-Ins menu to see the window shown in Figure 6-2.

Figure 6-2 The Assertion Sourcerer dialog box

The standard assertion procedure, which supplements the Debug.Assert functionality, is named BugAssert. It is part of a small Visual Basic 6 module named DEBUG.BAS, which you should add to any project in which you want to monitor run-time assertion failures. You can then specify which of your Debug.Assert statements you want converted to run-time assertions; the choices are all assertions in the project or just those in the selected form, class, or module.

The Assertion Sourcerer works in a very simple manner. When you use the Assertion Sourcerer menu option on the Add-Ins menu to request that assertion calls be added to your project, the Assertion Sourcerer automatically generates and adds a line after every Debug.Assert statement in your selected module (or the whole project). This line is a conversion of the Debug.Assert statement to a version suitable for calling the BugAssert procedure. So

 Debug.Assert bTest = True 

becomes

 Debug.Assert bTest = True BugAssert bTest = True, "bTest = True," _           "Project Test.VBP, module Test.CLS, line 53" 

BugAssert's first argument is just the assertion expression itself. The second argument is a string representation of that assertion. This is required because there is no way for Visual Basic to extract and report the assertion statement being tested from just the first argument. The final argument allows the BugAssert procedure to report the exact location of any assertion failure for later analysis. The BugAssert procedure that does this reporting is relatively simple. It uses a constant to not report assertion failures, to report them to a MsgBox, to report them to a disk file, or to report them to both.

Before compiling your executable, you'll need to set the constant mnDebug in the DEBUG.BAS module. Now whenever your executable is invoked by any other programmer, assertion failures will be reported to the location(s) defined by this constant. Before releasing your code into production, you can tell the Assertion Sourcerer to remove all BugAssert statements from your program.

Complete source code for the Assertion Sourcerer is supplied on the CD accompanying this book in CHAP06\assertion so that you can modify it to suit your own purposes.

Some final thoughts You can use the Assertion Sourcerer as a supplement to Debug.Assert when you want to implement assertions in compiled Visual Basic code.

Size Matters: The Metrics Sourcerer

Take any production system and log all the bugs it produces over a year or so. Then note which individual procedures are responsible for the majority of the defects. It's common for only 10 to 20 percent of a system's procedures to be responsible for 80 percent of the errors. If you examine the characteristics of these offending procedures, they will usually be more complex or longer (and sometimes both!) than their better-behaved counterparts. Keeping in mind that the earlier in the development cycle that these defects are detected the less costly it is to diagnose and fix them, any tool that helps to predict a system's problem areas before the system goes into production could prove to be very cost-effective. Step forward the Metrics Sourcerer. (See Figure 6-3.) This Visual Basic 6 add-in analyzes part or all of your project, ranking each procedure in terms of its relative complexity and length.

Figure 6-3 The Metrics Sourcerer dialog box

Defining complexity can be fairly controversial. Developers tend to have different ideas about what constitutes a complex procedure. Factors such as the difficulty of the algorithm or the obscurity of the Visual Basic keywords being employed can be considered useful to measure. The Metrics Sourcerer measures two rather more simple factors: the number of decision points and the number of lines of code that each procedure contains. Some evidence suggests that these are indeed useful characteristics to measure when you're looking for code routines that are likely to cause problems in the future. The number of decision points is easy to count. Certain Visual Basic 6 keywords—for example, If…Else…End If and Select Case—change the flow of a procedure, making decisions about which code to execute. The Metrics Sourcerer contains an amendable list of these keywords that it uses to count decision points. It then combines this number with the number of code lines that the procedure contains, employing a user-amendable weighting to balance the relative importance of these factors. The final analysis is then output to a text file, viewable by utilities such as WordPad and Microsoft Word. (By default, the filename is the name of your project with the extension MET.) You might also want to import the text file into Microsoft Excel for sorting purposes. There's no point in taking the output of the Metrics Sourcerer as gospel, but it would certainly be worthwhile to reexamine potentially dangerous procedures in the light of its findings.

Another factor that might be useful to measure is the number of assertion failures that each procedure in your program suffers from. This figure can be captured using the Assertion Sourcerer. Combining this figure with the numbers produced by the Metrics Sourcerer would be a very powerful pointer toward procedures that need more work before your system goes into production.

Some final thoughts Use the Metrics Sourcerer as a guide to the procedures in your programs that need to be examined with the aim of reducing their complexity. Economical to execute in terms of time, the Metrics Sourcerer can prove to be extremely effective in reducing the number of bugs that reach production.

A Black Box: The Instrumentation Sourcerer

When a commercial airliner experiences a serious incident or crashes, one of the most important tools available to the team that subsequently investigates the accident is the plane's black box (actually colored orange), otherwise known as the flight data recorder. This box provides vital information about the period leading up to the accident, including data about the plane's control surfaces, its instruments, and its position in the air. How easy would it be to provide this type of information in the event of user acceptance or production program bugs and crashes?

The Instrumentation Sourcerer, shown in Figure 6-4, walks through your program code, adding a line of code at the start of every procedure. This line invokes a procedure that writes a record of each procedure that is executed to a log file on disk. (See Chapter 1 for an in-depth examination of similar techniques.) In this way, you can see a complete listing of every button that your user presses, every text box or other control that your user fills in, and every response of your program. In effect, each program can be given its own black box. The interactive nature of Windows programs allows users to pick and choose their way through the different screens available to them. Thus it has traditionally been difficult to track exactly how the user is using your program or what sequence of events leads up to a bug or a crash. The Instrumentation Sourcerer can help you to understand more about your programs and the way they are used.

Figure 6-4 The Instrumentation Sourcerer dialog box

Configuration options allow you to selectively filter the procedures that you want to instrument. This might be useful if you want to document certain parts of a program, such as Click and KeyPress events. You can also choose how much information you want to store. Just as in an aircraft's black box, the amount of storage space for recording what can be a vast amount of information is limited. Limiting the data recorded to maybe the last 500 or 1000 procedures can help you to make the best use of the hard disk space available on your machine or on your users' machines.

Some final thoughts The Instrumentation Sourcerer can be useful in tracking the cause of program bugs and crashes, at the same time providing an effective record of how users interact with your program in the real world.