Delphi - Component Testing

Components that you design require additional testing above and beyond what normal code requires. This page will cover some of that and explain several problems that I have experienced.

Design Time vs Run Time | Placing the component on a form | The Destructor | Testing the Help Interface

Design Time vs Run Time

When you design a component, a subset of the code is run at design time. Specifically, when a component is placed on a form, the constructor is executed. So are the paint method, and a few others. Too bad there is no documentation to explain this.

In some methods, there will be code that is used only at runtime or only at design time. In the VCL, these are some typical ways to control this.

Using similar code When testing your code, it is important to test both parts of the code - both runtime and design time operation.

When you develop software, you can set runtime breakpoints and single step thru the code. Unfortunately, there is no way to single step thru your code at design time.

Placing the component on a form

What could be simpler than placing a component on a form? Yet, I have spent many days debugging problems related to just that. Unfortunately, I have no way to automate these tests - to do that you need to send mouse clicks to the Delphi IDE and then perform some very precise captures of pieces of the screen image. Granted, these are both possible, but I don't have those tools and don't have the time to write my own. As a result, this is a very visual task. While these tests may seem trivial, I had a component which contained several buttons. It took several days to figure out what needed to be done to pass these tests. Nothing seemed to work the way I expected.

In design mode, loaded is not called unless there is at least one non-default property value. Therefore, make sure that none of the required design time code is there (or called from there).

The Destructor

Always single step thru the destructor to make sure that there are no surprises. Typically, you want to make sure that none of the events are called (unless your design requires it).

For example, this destructor clears FOnChange and FOnChanging before destroying itself.

Testing the Help Interface

Developing a help interface is critical to completing a component.

The basic test procedure is to click everything that related to your component, press F1, and verify that the correct help page is displayed. Items that need to be checked include

On each help page, you need to click on each link and verify that it works.

Simple, huh. I find that writing and testing the associated help is at least as much work as developing the component itself.

Oh, by the way .. useful help is "easy" to develop for Delphi 5. Delphi 6 and 7 don't work near as well. Beyond that, the help system was changed (it now uses html help) and I have no idea how to make those work - they intentionally broke the F1 key. (Actually, this is the reason I have refused to upgrade - an IDE with worthless help has no value.)

Author: Robert Clemenzi
URL: http:// / Languages / Delphi / ComponentTesting.html