Wednesday, November 29, 2006

Debug Environment

Not to take too much time away from my series on testing applications and bullet-proofing source code, but I felt that a little time dedicated to setting up a proper debugging environment would be helpful. A developer should have a different set of tools available than the end user. These tools will give the developer the ability to stop program execution, run some utilities, start a coverage, track events, etc.

Below are the main features of a debugging environment that I find important. Because the implementation can be done in several ways, I won't get bogged down into the details at this time. Perhaps I will address one or two of these in a future article:

1.) A global debug flag. This flag would be part of a custom application object that can be used to determine whether or not the debug features are present or absent in the current instance of the application. Setting the flag can be done in a config file, a setup table, or even via a parameter during execution. The flag should be smart enough to know if the application started from the VFP command window (or the program/do menu) or via a desktop shortcut. We want to avoid 'feature not available' errors; we would also like to remind the developer that he or she is trying to run debug mode from a shortcut.

2.) A custom error handler. It is highly recommended to include custom error handling at the class level (via a form, container, textbox, etc). But there should also be a global handler that can address any issues that arise otherwise. These error handlers must be smart enough to recognize when a developer is in debug mode. These methods should give the developer a means to suspend execution (perhaps by spitting out the default VFP error notification) and to save environment settings for further research.

3.) A debug menu. When in debug mode, a special menu called 'Debug' should be created; pop it in right after the help menu. The menu should contain some useful features, such as a SUSPEND command; window activation (Trace, Command, Data); Coverage and Event logging; ability to open log files and tables; perhaps the ability to output information about the current environment, call stack, and objects; and various custome functions and programs not available to the end user. In addition, it should be chock-full of utilities and functions that can be called when needed.

4.) There should be a built-in restore mechanism that will automatically restore key labels, menus, and the VFP environment at anytime. Coupled with this would be a mechanism to cancel the program in a clean way for the developer.

This is the bulk of what is required for a proper debugging environment. These additions could save hours during debugging sessions. Exploring them further is well worth the effort.

No comments: