Self-Testing Applications

A self-testing application is a Connected Application that uses the TestComplete OLE engine to test itself. This technology appeared in one of early TestComplete versions and provided a number of benefits at that time: easier access for test commands to internal objects, methods and properties of tested applications, better control over test execution, creating complex checkpoints, easier creation of unit tests. However, as the product evolves, these benefits have come to naught. Now, this technology is obsolete. It will be removed from the product in one of the future versions.

We do not recommend using Self-Testing Applications for creating new tests. The topics below are for those who have not stopped using this technology yet:

• Self-Testing Application should simulate user actions (clicks, double-clicks, keypresses, etc.) after TestComplete starts executing a script. Otherwise, an error will occur.

• When you launch a thread for script-type code, each TestComplete call will be an OLE call. Windows requires that the COM model be initialized for each thread that has these calls, otherwise they will fail. Your input-simulation thread must begin with a call to CoInitializeEx.

• Due to specifics of the TestComplete engine, manual tests cannot be executed from Self-Testing Applications.

• There is one special point to be aware of when a Connected Application tests itself. If the application uses onscreen objects to simulate mouse or keyboard input, then a deadlock may occur unless the input-simulation code goes into a separate thread from the ordinary application code. This applies whether the simulation is script code you recorded and then imported into the application, or if you wrote it directly into the source.

  Suppose your test code simulates a button press on a main-thread control:

  myButton.Click();

  If this code runs in the same thread as the control, then the application will not be able to process the click. It will be running the TestComplete click code instead. Eventually, it will regain the freedom to handle the control event, but at best it will not be running as it would without the self-testing.

  You may mistake this as either the application or the code imported from TestComplete, when the problem is that the recorded code should have run in a separate thread. (TestComplete runs in a separate process from the application.)