Question

(This might be better in the TestComplete forums, but I thought I’d give it a shot here anyway)

We are looking in to automated testing of our Delphi 2010 application with TestComplete. The main control that our application uses is our own custom control that derives directly from TCustomControl.

(For reference the control is like a digraming tool that display boxes with text in them. These boxes can be selected. the control is completely custom drawn, including the selection).

We are looking in to making this more TestComplete friendly so we can read data out of it (e.g. what data is loaded in to the control, what data is selected)

I should also mention that our application uses an MVC architecture and makes heavy use of interfaces. TestCompletes debug agent can’t seem to return any type information about interfaces and thus we can’t get any data from them. I suspect this is the root of our problem

I’m considering these two approaches:

1. Add new properties to the control that will return information about the currently selected box(es). e.g. text in the box, position on screen, hierarchical path, and access them via TestCompletes debug agent.

2. Look at creating a custom control add on for TestComplete (I’m not even sure you can do this with Delphi controls)

The problem with the first approach is the linker will often elimate properties and functions if they are not being used. We want to use our release build for testing not a debug build.

Does anyone have any advice on this or experience with this type of thing?

Thanks

Edit: I’ve just read the SDK help and custom control addons can only be created for .net and WPF controls.

Answer 1

You are right about the debug info – you can strip it out from the release build. Thus, you will test a release build and have access to internals at the same time.

A note regarding this situation: “the linker will often elimate properties and functions if they are not being used.” You can cheat here to make the linker generate debug info for those funcitons:

1. Make the funcitons published. The linker does not touch published elements.
2. Make the funcitons virtual. The linker does not exclude virtual methods.
3. Call your functions somewhere in your code. To include the call in your code without actually calling anything, you can do something like this:

var t: Boolean;
begin
  t := False;
  if  t = True then
    TheFunctionThatNeverExecutes();
...
end;