Making a custom control more testable in TestComplete

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 should reconsider your decision to use the release build for testing. The reason is that TestComplete needs some magic to make your testing life easier while you don't want this magic be present in the release build. So if you can elaborate on the reasons for not using a debug build for testing, we can try to find a solution to revoke this decision. The result may be that you will have access to all the relevant data of your control if you only reveal all available power of TestComplete.

Now back to the original question: You can overcome the interfaces problem by creating some special classes that wrap those interfaces and thus make the properties available in TestComplete.

Create a small (perhaps invisible) test form where you centralize access to instances of these classes. (Now the release mode link) Only create this form in debug mode so, when carefully designed, you only link in the relevant code when needed for testing.

Answer 2

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;