Extending Delphi Application Testability With External Debug Info

  May 26, 2009

In my previous blog post, TestComplete 7 Improvements — Delphi and C++Builder Open Applications, I told you that TestComplete can now see inside Delphi applications without any special preparations. Still, even more thorough testing can be achieved if the application is compiled with debug information included. This enables TestComplete to access all “native” (published, public, protected and private) properties, fields and methods of application’s objects just like Delphi’s integrated debugger can.

However, the debug information requirement raises the following problems:

  • Inclusion of debug information significantly increases the application size, impairs the performance and thus makes the application non-suitable for shipping. As a result, build engineers need to create a special, debug application version in addition to the release version.
  • The need to create an additional version increases the total build duration and the application can’t be built as often.
  • The application may function differently when built with debug settings, so the debug version being tested may function differently from the release version shipped to users.

TestComplete 7 provides a solution to these problems and lets build engineers create testable release builds of Delphi applications with external debug information. This can be accomplished by using TestComplete’s new utility — StripTDS (<TestComplete>BinStripTDS.exe). It strips debug information from executables and libraries created with the Delphi compilers and saves it to a separate TDS files next to the processed ones. During application testing, TestComplete reads the TDS debug information as if it were inside the application’s binaries, and exposes internal properties, fields and methods of the application’s objects, which then can be used in your automated tests. There’s now no need to create special application builds for TestComplete; it can now test your normal release builds using external debug information.

Creating release builds of a Delphi application with external debug information includes two steps:

  • Building the application with internal TD32 debug information.
  • Extracting debug information from the application’s binaries using TestComplete’s StripTDS utility.

I’ll show you how this can be done with a Delphi version of TestComplete’s sample application, Orders. The Orders application is located in the <Users>PublicDocumentsTestComplete 7 SamplesOpen AppsOrdersDemoDelphi folder on Windows Vista and Windows Server 2008 or the <Documents and Settings>All UsersDocumentsTestComplete 7 Samples folder on other Windows versions. In this little tutorial, I use CodeGear Delphi 2009 on Windows XP, but the steps for other Delphi and Windows versions are very similar.

First, I’ll compile Orders with internal TD32 debug information. The steps to do this are as follows:

  • Open the Orders.dpr project in Delphi.
  • Open the project options.
  • For CodeGear Delphi 2007 or later, select the Release build configuration.
  • Enable the Debug Information and Local Symbols options in the Delphi Compiler | Compiling category:

  • Enable the Debug information option in the Delphi Compiler | Linking category:

Project Options for SampleApp.exe: Delphi Compiler - Linking Category

  • Save and close the project options.
  • For CodeGear Delphi 2007 or later, activate the Release build configuration.
  • Build the project.

Now I have the Orders executable built with debug information included. The file size is ~4.6 MB; out of these the application’s binary code takes ~900 KB, while the rest is debug info. To extract debug info into an external file using the StripTDS utility, I run the following command:

"C:Program FilesAutomated QATestComplete 7BinStripTDS.exe" -w "C:Documents and SettingsAll UsersDocumentsTestComplete 7 SamplesOpen AppsOrdersDemoDelphiOrders.exe"

Note: Here, the -w argument specifies that StripTDS should replace the resulting debug information file if it already exists. You can read more about StripTDS’s command line in TestComplete’s help.

After processing the Orders executable with StripTDS, I get two files:

  • Orders.exe (~900 KB) — this is the application’s stripped binary file; the release version clear of debug info and ready for shipping to users.
  • Order.tds (~3.7 MB) — this file contains debug information extracted from Orders.exe. This file isn’t needed to run Orders; it’s only used by TestComplete. For testing purposes, this file must be kept in the same folder as Orders.exe.

Let’s launch Orders and view it in the Object Browser. For TestComplete 7, there’s no difference whether the debug information is included in the application’s binary files or kept outside of them. Notice the object’s internal properties, fields and methods that became accessible to TestComplete’s automated tests due to debug info:

VCL object properties in TestComplete's Object Browser

VCL object fields in TestComplete's Object Browser

VCL object methods in TestComplete's Object Browser


The new StripTDS utility included in TestComplete 7 provides a solution for Delphi application developers that want to create testable release builds. Now they don’t need to build an additional debug version to run automated tests on, or worry that the build being tested is different from the one shipped to users. StripTDS makes it possible to keep debug information needed for test automation out of the application’s binaries, so that the application size isn’t increased while ensuring that the application can still be adequately tested and accessible beyond the UI. It’s a good idea to run StripTDS as part of your automated build process, but I'll tell you more about this next time.

By the way, if you haven’t tried TestComplete 7 yet, you are missing a lot of great test automation capabilities. So, download TestComplete free and try it today. And let us know what you think about it — your feedback is greatly appreciated, as always.