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.

if not (csLoading in ComponentState) and (not (csDesigning in ComponentState) then

if (IsVisible or (csDesigning in ComponentState)) then

if not (csDesigning in ComponentState) then

if     (csDesigning in ComponentState) then

Using similar code

The code ignores the visible property and always displays components during design mode, yet the visible property controls the display at runtime
Developer defined events are not called in design mode
Various windows messages (like the mouse click) are routed to the design interface (to select the component) or the components itself (eg, to depress a button)

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.

Place the component on the form without resizing it	This verifies that the height and width are set in the constructor. If either of these is missing, the component will not be displayed.
Resize the component and verify that it looks the way you expect	This verifies that the height and width trigger the correct routines.
Add a component to the form using a non-default size	This verifies that the height and width properties are working.
With several components on a form - some at the default size and others at a different size - save and reopen the form	Problems in the constructor will affect the "default sized" components, other problems will affect the resized components.
View the form design in text mode and verify that the saved properties are as expected	Properties that store integer, boolean, and enumerated values may be defined with a default value using the default directive. If the default values are used, then they are not stored in the *.dfm file or displayed in the text version.

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.

destructor TStringList.Destroy;
begin
  FOnChange := nil;
  FOnChanging := nil;
  inherited Destroy;
  if FCount <> 0 then Finalize(FList^[0], FCount);
  FCount := 0;
  SetCapacity(0);
end;

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

The icon in the component palette
The Component once it is placed on a form
In the component property editor, check every property and event
In the code, check every property, event, and method

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