Debugging and Testing

All applications need testing. Too many bugs can find their way into an application during the programming stages. When you test an application, you run it through a series of test-case executions. During the testing, you enter random and extreme values in all the user-entry controls to ensure that the application can handle values outside the typical range. You'll find that bugs almost always appear during the testing phase.

Debugging is a three-step routine:

  1. Determine the problem bugs and their locations
  2. Correct the bugs
  3. Retest the application to ensure that you eliminated the bugs

Bugs range from mild errors, such as misspellings or text-alignment mistakes, to serious errors, such as when an application terminates the entire Windows session and loses data. To your users, a bug is anything that doesn't match expected program results or prevents the application from running.

Programmers face many debugging problems when looking for bugs. You must decide that you've found as many bugs as you can possibly find, and you must test and retest to ensure that the bugs are gone and don't reappear. Careful planning before, during, and after the coding process helps you reduce the time it takes to debug your application.

tip

You should develop and test your application from within the Visual Basic development environment. The development environment contains debugging tools that help you track and locate errors. Only after you're satisfied with your test results should you then compile and distribute your application to users.

Windows and the powerful Visual Basic development environment help you locate errors. When you run a Visual Basic application, Visual Basic might find an error during the compilation or preparation for the program's execution (such as a misspelled keyword) and display an error message, such as the one shown in Figure 21.l.

Figure 21.1

Visual Basic helps you locate bugs.

If, when you run an application, you see such an error message before the first form appears onscreen, you probably typed a syntax error in your code. The error in Figure 21.1 is a syntax error. The error message rarely reads "Syntax Error," but if an error occurs due to a spelling or grammar mistake, the error was a result of a syntax problem.

note

A syntax error is an error in a programming language's grammar or spelling.

Notice that Visual Basic not only told you about the error in Figure 21.1, but it also located the error inside the code window. Even if the code window is closed when you try to run the program, Visual Basic highlights the error. The problem is that a proper End statement was not used. After you fix the syntax error, you then can click the Run toolbar button to start the program from the corrected error.

If you have the Auto Syntax Check box selected on the Tools|Options dialog box's Editor page, Visual Basic checks for syntax errors as you type program code into the code window. Some programmers, however, like to have more freedom at design time to sprinkle partial statements here and there that they will repair later in the programming process. However, such incomplete code can lead to errors later if you're not careful; you may forget to correct a statement that you've left undone. Nevertheless, there are times when you'll want to fill in gaps of code at a later time, perhaps after checking with the users to answer a design question.

Therefore, you can turn off automatic syntax checking. When the option is off, Visual Basic doesn't check for coding errors, such as a missing parenthesis, until you run or compile the program. Either way, Visual Basic locates these kinds of bugs for you with message boxes, such as the one shown in Figure 21.1, but the Auto Syntax Check option gives you the choice of when you want Visual Basic to tell you about the code problem.

More difficult errors appear during the runtime of your application. A syntax error is easy to spot, because Visual Basic finds it for you. A runtime error is more difficult to locate and correct. Consider the error shown in Figure 21.2. The error involves program logic. No error message appears, but the field that should show a name shows an address instead. Obviously, an address field was loaded where a name field should appear. Visual Basic does know this is unusual because it just follows the programmer's orders, even if logic errors result.

Figure 21.2

Visual Basic cannot catch logic errors.

Logic errors that you catch require that you stop the program. (Visual Basic doesn't recognize the error and stop the program as it does with syntax errors.) You then must track down the problem.

To track the problem, you must search through the program code looking for traces where such a runtime logic error might reside and then fix the problem. If the problem involves the form's or a control's appearance onscreen, you have to trace all references to that part of the object. Often, but not always, the Object Browser can help you find the specific code that goes with an object.

Visual Basic can locate some logic errors if the logic error results in a request for Visual Basic to do something impossible. For example, Figure 21.3 shows what happens when a program asks Visual Basic to divide a number by zero. Division by zero isn't defined mathematically, so Visual Basic cannot accomplish this calculation, even if no syntax errors appear in the calculation. Visual Basic halts the program's execution and describes the error in a message box.

Figure 21.3

Some logic errors request that Visual Basic attempt something impossible.

The application runs smoothly without the code window showing. However, as soon as Visual Basic realizes that the program is requesting an impossible task, it displays the code window and locates the approximate place in the code where the division by zero occurs. You can click the error dialog box's Help button to get more help with the error message, click End to terminate the program's execution, or click Debug to enter Visual Basic debugging mode.

tip

Notice that a division by zero error produces the error code 11 (see the error message in Figure 21.3). You can test for errors in the Err.Number system object. Therefore, if you suspect that a calculation may result in a division by zero error, due to missing data, you can trap the error with an On Error Goto statement. If the offending Err.Number is 11, you can inform the user that a value is not filled in on the form instead of the user having to deal with an error message box.

Top Home