Tester 'll Never " Satisfied "

Introduction

Introducing TestComplete
TestComplete is an automated testing environment for Win32, .NET and WPF applications. It provides extended support for testing Web pages, Web servers and projects created in Microsoft Visual C++, Visual Basic, Borland Delphi, C++Builder, Java, .NET and WPF development tools.
TestComplete manages scripts to test applications externally, self-testing by the applications themselves, and many inside-outside forms of tests. It is oriented equally to unit testing and to functional testing, provides superior support for daily regression testing and supports many other kind of testing (data-driven testing, object-driven testing, etc.)
If you are new to TestComplete, see Getting Started to learn how to use the product.
To get to know basic concepts, please read TestComplete - Product Overview (this topic is part of the Getting Started section).
A note about plug-ins: TestComplete’s entire architecture is COM-based. Most of the features you see in the product are supported through plug-ins. When the plug-in is meant to remain for the life of the current version, it is made an internal part of TestComplete.exe. When it is possible that the plug-in could be updated, it is left external (such as the database-access plug-ins). Others will be added to the AutomatedQA Web site (http://www.automatedqa.com), and users can write their own plug-ins using the supplied interface documentation and libraries – several user-contributed plug-ins are in http://www.automatedqa.com/downloads/plugins.asp.
In fact, there are so many “open” features to TestComplete that we have put a checklist into a separate topic, Open Access.
Difference Between Standard and Enterprise Editions
There are two editions of TestComplete: Standard and Enterprise. The following matrices explain differences between them.
Features Supported by Both Standard and Enterprise Editions
Features Standard Edition Enterprise Edition
Black-box testing
(functional testing of any Windows application) + +
Extended support for .NET applications + +
Extended support for Microsoft Visual C++ applications + +
Extended support for Microsoft Visual Basic applications + +
Extended support for Java applications + +
Extended support for Borland Delphi applications + +
Extended support for Borland C++Builder applications + +
Support for 64-bit applications + +
Extended support for applications using Microsoft Active Accessibility (Microsoft Visual FoxPro, Microsoft Access, etc.) + +
UI Automation technology support + +
Extended support for WPF (XAML) applications + +
Extended AQtime integration and coverage testing + +
Testing applications running under another user account + +
Support for third-party grid controls + +
Support for third-party menus + +
Scripting and script debugging + +
Event handling + +
Unit testing
(including support for MSTest, JUnit, NUnit and DUnit unit tests) + +
Functional testing (or user interface testing) + +
ActiveX objects support + +
Low-level recording and playback + +
Name mapping + +
Object-driven testing + +
Data-driven testing + +
Source code control integration + +
User forms + +
Calling functions located in .NET assemblies + +
Calling functions located in DLLs + +
ADO and BDE support + +
CORBA support + +
Compression of test results + +
Features Available in the Enterprise Edition Only
Features Standard Edition Enterprise Edition
HTTP load testing - +
Network suite (distributed testing) - +
Functional testing of web pages (web testing) - +
Testing of web services - +
Optical character recognition - +
Microsoft Visual Studio 2005 integration - +
Issue-tracking support - +
TestExecute - +
TestRecorder - +
TestComplete Enterprise Edition includes special plug-ins that allow you to simulate virtual users and perform the load, stress and scalability testing of your Web servers. The basic TestComplete Enterprise license supports only 5 virtual users. You can purchase versions that support more virtual users. For detailed information, please visit AutomatedQA's web site:
 http://www.automatedqa.com/products/testcomplete/tc_matrix.asp
System Requirements
Supported Operating Systems
• Microsoft Windows Vista (both 32-bit and 64-bit editions).
• Microsoft Windows Server 2008 (both 32-bit and 64-bit editions).
• Microsoft Windows XP (both 32-bit and 64-bit editions).
• Microsoft Windows Server 2003 (both 32-bit and 64-bit editions).
• Microsoft Windows 2000.
• Microsoft Windows NT with Service Pack 6 or later.
• Microsoft Windows ME.
• Microsoft Windows 98.
If you use a computer that has several processors or a multiple-core processor (for example, dual-core CPU) and has Windows XP Service Pack 2, then you must install the Windows update #896256 in order for TestComplete to be able to record user actions correctly. The update is available on Microsoft’s web site:
http://support.microsoft.com/kb/896256

In order to install TestComplete, you must be logged on under the administrator account on the local computer. To register TestComplete, administrator permissions are not required.
For information on using TestComplete and the Windows Firewall, see TestComplete and Windows Firewall in TestComplete help.
For more information on working under Windows Vista and Windows Server 2008, see Testing Applications With TestComplete Under Windows Vista and Windows Server 2008 in TestComplete help.
Minimal System Requirements
• Intel Pentium II 400 MHz or higher.
• Microsoft Windows 98 or later.
If you use Windows XP Service Pack 2 on a computer with several processors or a multiple-core processor, you must install Windows update #896256 in order for TestComplete to record user actions correctly. The update is available at http://support.microsoft.com/kb/896256.
• Microsoft Internet Explorer 5.0 or later.
• 128 MB of RAM.
• 470 MB hard disk space.
• VGA (640 × 480) or higher resolution monitor.
• Mouse or other pointing device.
Recommended System Requirements
• Intel Pentium 4 3 GHz, Intel Core 2 Duo 2 GHz or higher.
• Microsoft Windows XP or later. Also, it is recommended that you install the latest service packs and updates for your operating system.
Note again, that if you work under Windows XP Service Pack 2 on a computer with several processors or a multiple-core processor, you must install Windows update #896256 in order for TestComplete to record user actions correctly. The update is available at http://support.microsoft.com/kb/896256.
• Microsoft Internet Explorer 6.0 or later.
• 1 GB of RAM on Windows XP and Windows Server 2003.
2 GB of RAM on Windows Vista and Windows Server 2008.
• 500 MB hard disk space.
• SXGA (1280 × 1024) or higher resolution monitor.
• Mouse or other pointing device.
Additional Requirements
• To test Java Open Applications, you must have one of the following Java virtual machines installed on your computer:
 Sun JDK (or JRE) v. 1.1.8 - 1.6.
 MSVM, build 3309 or later.
 BEA JRockit 5.0.
• To test .NET Open Applications, the Microsoft .NET Framework v. 1.0.3705 or later is required.
• To execute TestComplete tests from test projects created in Microsoft Visual Studio 2005, Microsoft Visual Studio 2005 Team Suite ver. 8.0.50727.42 or later or Microsoft Visual Studio 2005 Team Edition for Software Testers ver. 8.0.50727.42 or later are required.
• To install TestComplete’s Microsoft Visual Studio 2005 Team Foundation Integration package, Microsoft Visual Studio 2005 Team Foundation Server Release is required.
• To perform load testing of Web servers, Microsoft Windows 2000, Window XP, Windows Server 2003 or Windows NT with Service Pack 6.0 or later is required. Also, it is recommended that your computer meets the following requirements:
 Minimal Configuration
- Intel Pentium III 800 MHz.
- 256 MB of RAM (for 300 virtual users).
 Recommended Configuration
- Intel Pentium 4 3 GHz with HyperThreading, Intel Core 2 Duo 2 GHz or higher.
- 1 GB of RAM (2 GB on Windows Vista and Windows Server 2008).
To install and run load testing samples, Microsoft Internet Information Services 5.0 or later are required. Also, to run load testing samples under Windows Vista, you should modify some of the IIS settings. For more information on this, see Running Load Testing Samples Under Windows Vista in TestComplete help.
Supported Development Tools
“Will TestComplete test my application?” - This is probably one of the first questions our clients ask about TestComplete. As a matter of fact, TestComplete does not depend on any development tool. It can simulate user actions (keypresses, mouse movements and clicks) under any application no matter whether this application was created in C#, Visual C++, Delphi or Java. However, in most cases, this kind of testing (testing via GUI) cannot provide reliable and thorough results. Quite often, QA engineers need access to the application internal objects, methods and properties. This is required, for example, for unit testing. You can get this access using TestComplete. It “opens” the internal objects, methods and properties up to private object elements in applications that were created with the following development tools:
All existing .NET compilers. For instance:
Microsoft: Visual C#, Visual Basic .NET and Visual C++ .NET v. 7.0 and later (managed code) (Visual Studio v. 8.0 only with Service Pack 1 installed), JScript .NET
Non-Microsoft: Borland C#Builder, Borland Delphi for .NET (Delphi 8 and Delphi 2005), Python .NET, Cobol .NET, Perl .NET, etc.
Microsoft Visual C++ 6.0, Visual C++ 7.0 and later (unmanaged code) (Visual Studio v. 8.0 only with Service Pack 1 installed).
64-bit .NET, Java and Windows applications (see Testing 64-bit Applications in TestComplete help).
Microsoft Visual Basic 6.0
Borland Delphi 3.0 and later (including CodeGear Delphi 2007)
Borland C++Builder 3.0 and later
Any Java development tool that supports one of the following Java virtual machines:
 Sun JDK (or JRE) v. 1.1.8 - 1.6. TestComplete also supports 64-bit JRE 1.6 applications.
 MSVM, build 3309 or later
 BEA JRockit 5.0
For instance, you can use Microsoft Visual J++ 1.1, Borland JBuilder 3.0, Sun Forte 1.0 and other development tools. The AWT, SWT, Swing and WFC library classes are also supported.
Sybase PowerBuilder 10.0 and later
Microsoft FoxPro 7.0 and later
Microsoft Office Access 2003 and later
Microsoft Office InfoPath 2003 and later
Since TestComplete can test any Windows application via GUI, it can simulate keypresses and mouse clicks in any Internet browser. This allows you to test Web pages working with any Internet browser. However, currently, you can only access properties and methods of HTML elements on a Web page shown in Internet Explorer, Firefox or in any instance of the Web Browser control. See Web Testing in TestComplete help for complete information on this.
As for the performance, load, stress and scalability testing of Web servers, they do not depend on Internet browsers (Internet Explorer, Netscape Navigator, Mozilla, Opera, etc.), the server type (Microsoft IIS, Apache, etc.) or platform (Windows, Linux, etc.) That is, with TestComplete you can perform these kinds of testing for any Web server working on any platform. Please see Load, Stress and Scalability Testing of Web Servers With TestComplete in TestComplete help.
Technical Support and Resources
If you have questions, problems or just need help with TestComplete, please contact our e-mail support team at:
 support@automatedqa.com
For information on our support policies, please visit our web site www.automatedqa.com/support.
You can also ask questions, search for answers, exchange comments and suggestions on our newsgroup and on the Community web site:
 forums.automatedqa.com.public.testcomplete
 http://www.automatedqa.com/community
You can find answers to your question in the list of the frequently asked questions which is available at:
 http://www.automatedqa.com/products/testcomplete/faqs/tc_faqs.asp
Take part in TestComplete training seminars offered by AutomatedQA. To learn more about training services, please follow this link:
 http://www.automatedqa.com/support/training.asp
Learn more about using TestComplete from technical papers published at:
 http://www.automatedqa.com/techpapers/
Make sure you regularly visit the AutomatedQA Web site, http://www.automatedqa.com, where you will find -
• News
• Updated support options
• Downloads, such as plug-ins and free tools
• Hot Stuff contributed by experienced users and the AQA team (hands-on solutions, code, plug-ins, etc.)
Getting Started
TestComplete – Product Overview
User Interface – Overview
The user interface of TestComplete consists of panels, the main menu and toolbars. The general layout is as follows:

Most of TestComplete’s screen area is occupied by panels. Panels are where you do your actual work and get your results. Each panel serves a separate purpose for your work in TestComplete. There are three “main” panels:
Panel Description
Project Explorer Displays the contents of the project suite, its projects and project items.
Workspace This panel is your work space in TestComplete. It holds a set of tabbed pages, in which you can modify properties of project items. When you double-click an item in the Project Explorer, TestComplete opens the appropriate tab page in the Workspace panel.
Object Browser TestComplete "sees" a lot of the applications under test, as well as all applications running on the machine. The Browser shows all of this in a navigational tree format. Everything that can be found in the Browser can be used in a test - the Browser is your test-object map, using the universal TestComplete object model. Names and values can be copied from the Browser and pasted to scripts. Values of all kinds can be saved from the Browser to Stores for later comparison.
There are more panels that are used for editing and debugging script code:
Panel Description
Bookmarks Shows a list of bookmarks set in the script code. Used for script editing.
Search/Replace Results Displays results of the search or replacement operations.
Watch List Used for script debugging. Shows variable and property values during test runs.
Call Stack Used for script debugging. During script execution, it shows the stack of function calls that led to the execution of the current routine.
Breakpoints Displays information about breakpoints. Used for script debugging.
Locals Displays information about the available script variables that are used for script debugging.
Code Explorer Navigates through scripts that are kept within the project. Used for script editing and debugging.
The size and layout of panels is not fixed. You can change panel sizes by dragging the separator between them. However, the most important point about handling panels is how they can be moved around - docking. Docking is our way of providing you with the most flexible workspace for the particular task you are interested in. It means that the entire work area can be reconfigured as needed, even beyond what is possible with toolbars (moving, hiding, etc.). Docking of panels in TestComplete is similar to docking windows in Microsoft Visual Studio .NET. For more information, see Docking in TestComplete help.
There are some common ways of arranging columns and lines in the grids, which most panels display. For instance, you can change the columns’ width, add or hide certain columns, sort data on a column by clicking the column’s header and perform other operations. See Arranging Columns, Lines and Panels in TestComplete’s help for more information.
Each panel has a number of options that you can modify in the Options dialog. To display the dialog, select Tools | Options from TestComplete’s main menu. General settings of the panels can be changed in the User Interface dialog. To display it, choose Tools | Options from TestComplete’s main menu and then select General | User Inerface in the ensuing Options dialog.
To save the current panel layout to a file, select View | Desktop | Save Docking to File from TestComplete’s main menu (by default, these files have the .qtdock extension). To load the panel layout from a file, select View | Desktop | Load Docking from File. To restore the default panel layout, select View | Desktop | Restore Default Docking. The Save Desktop As and Load Desktop items of the View | Desktop submenu will save and load the panel layout along with the toolbar settings.
TestComplete's interface receives commands in four ways:
• Through menus.
• Through popup menus (right-click, context-dependent).
• Through toolbars.
• Through keyboard shortcuts.
Keyboard shortcuts are especially useful during recording, since they let you command TestComplete without moving the focus off the tested application. These shortcuts can be customized with the Global Shortcut Options dialog.
As in Microsoft Word or Excel, menus are a type of toolbar, and both can be customized as needed. You can also create your own toolbars. By default, toolbars are docked at the top of the TestComplete window. You can easily dock them to any other edge by dragging them to the left, right or bottom edge of the window. To remove or add buttons, you can either call the Toolbar Customization window or use the Quick Customization feature. See Toolbars Customization in TestComplete help for more information.
To save or load the current layout of toolbars and toolbar items, use the View | Toolbars | Save Toolbars to File and View | Toolbars | Load Toolbars from File menu items. To restore the default toolbar layout, select View | Toolbars | Restore Default Toolbars. To save and load the layout of panels, menus and toolbars, use the View | Desktop | Save Desktop As and View | Desktop | Load Desktop menu items.
About Projects and Project Items
Projects and Project Suites
Similar to program development tools, such as Microsoft Visual Studio or Borland Delphi, the primary unit of management in TestComplete is a project. A project contains data and files (project items) that are needed to perform tests as well as a cumulative log of all test runs since the start of the project.
Related projects can be united into a project suite that contains one or more projects. TestComplete automatically generates a project suite when you create a new project. You can also create empty project suites and then use TestComplete’s dialogs to fill the suite with the desired project files.
Project Items
Project items are elements that perform various testing operations or assist in performing these operations. Each project item is a collection of child items and files. By default, the child items are stored in files located in subfolders of the project’s folder.
The Project Explorer panel provides a graphical interface to view and manage the projects, project suites and project items:

For complete information on project items available in TestComplete, see About Project Items in TestComplete help.
To view or modify properties of a project item or properties of its child element, right-click the desired item or element in the Project Explorer panel and choose Edit from the context menu, or simply double-click the item (or element). TestComplete will show the property editor in the Workspace panel:

In addition to the editor displayed in the Workspace panel, TestComplete offers other helper panels and windows for some project items to make editing more convenient. For instance, TestComplete includes the Code Explorer panel which makes it easier to navigate through script units.
About Test Items
Most project items can be used to perform testing actions. For instance, Script and Low-Level Procedures can simulate user actions; HTTP Load Testing can simulate the user activity over a Web server, and so forth. In other words, a project item can be used as a source of the entire test or a part of the test (we call these parts test items). The sequence of test items to be run is specified in the Test Items page of the project editor. A project itself can be used as a test item when you create tests for project suites. For more information, read Creating Tests.
TestComplete User Interface and Object Browser
TestComplete’s desktop is organized into a number of panels (see User Interface – Overview):

The Project Explorer panel displays a tree of project items, their child elements and test log nodes. The Workspace displays editors for the selected project item as well as test log pages.
The Object Browser panel holds one major TestComplete function that does not belong to a specific project. The Object Browser maps all processes currently running on the machine, whether they are an application for testing, a basic operating system service like the Explorer process, or some other application like Internet Explorer or TestComplete itself. For each process it shows all objects accessible externally through TestComplete facilities, and all of the accessible object properties and methods. It also shows the simulated user actions possible on the object; these are simply called actions.
In other words, the Browser tells you everything that is available for external testing, and how to get to it. It also lets you take screen clips (by window objects or by rectangle) and store them as images with the current project. It does the same for any collection of object properties you may wish to store. Finally, there are several ways of copying information from the Browser to the clipboard, or directly into scripts.
The fastest way to understand how TestComplete supports external testing is to spend some time in the Object Browser. See Exploring Application Properties in TestComplete help.
TestComplete’s Test Log
Each project holds a log of all project runs. In fact, the best definition of a project is “what TestComplete maintains a log for”. Everything else is secondary. The log is where you get the results of the entire testing exercise.
The basic unit of the log is a test. The log itself is an object that can be called in scripts or code. Using TestComplete in the simplest way, you launch a test by right-clicking a project or project item in the Project Explorer panel and selecting Run from the context menu. The log is smart enough to know that the current test starts when the project item’s execution begins, and ends when the execution stops. A project item (for example, script) can call other project items or run applications that access the Log object - the “current test” goes on until the execution of the “parent” item is finished. The only thing you cannot do is run several tests on the same computer in parallel.
For each test, the log records start, stop, duration and completion (non-completion means the test could not continue to the end).

The log has a tree-like structure similar to the structure of the executed test items. Each node in this tree has a specific format of results. This format depends on the project item, in which a test item is based. For instance, the log of a script execution is a tree-like structure of messages of various kinds. TestComplete supports a large variety of ways to differentiate these messages:
• It automatically logs the exact message time, so you can get the time spent between any two messages.
• Each message is posted according to one of the following message types - Error, Warning, Picture, File, Link, Event and the ordinary Message (called information message in the Help to differentiate it from other messages).
• Each message also has a priority level.
• Messages contain text and additional comments (or remarks). Each message can also have an image associated with it.
• Related messages can be organized into folders within the log.
• Finally, filters can be defined to create reports of any type.
If your script or other test code does not post messages to the log, the only messages you will find are possible error messages from TestComplete itself. Therefore, unless you are simply trying out a test, the one thing it must do is post messages. This cannot be recorded, you have to write script code for it.
Stores and Checkpoints
A typical test performs a lot of comparisons. Comparisons are the core of regression testing. One regression test can involve thousands of comparisons. Other forms of testing also need a validated reference during automation.
To support the comparison, you can add the Stores project item to your test project. This project item contains various elements that are saved along with the project for comparison purposes. We call the comparison or verifying operations checkpoints. The Stores project item contains elements that are used to create checkpoints.
The elements are organized into a number of collections. Currently, the item includes the following collections:
• Regions - Contains elements used to compare images and find one image within another.
• Files - Contains elements used to compare files.
• Objects - Contains elements used to compare properties of an object or window.
• DBTables - Contains elements used to compare and verify data of a database table, view or query.
• Tables - Contains elements used to verify data of controls that display information in tabular form as well as data of list view, list box and combo box controls.
• WebTesting - Contains elements used to verify web pages and compare them.
• XML - Contains elements used to compare XML documents and check web service responses.
Each Stores collection has a corresponding program object which contains methods that automatically perform the comparison (or verification) operations and report the results. That is, to perform the comparison or verification, you should call the appropriate method in scripts. For instance, to compare images, you call the Compare method of the Regions object.
You can perform the operations needed for creating the comparison code manually, or you can create this code by using TestComplete’s wizards and dialogs. Using the wizards and dialogs greatly simplifies the creation of the comparison code (that is, they simplify the creation of checkpoints).
You can create checkpoints at design time by selecting items of the Tools toolbar or you can create checkpoints during test recording through the Add Checkpoints item of the Recording toolbar:

Upon selecting the menu item, TestComplete displays a dialog or wizard, in which you specify the checkpoint parameters. After closing the dialog (or wizard), TestComplete generates the verifying script statements, which you insert into your script code.
For more information on creating checkpoints and verification code, see About Checkpoints in TestComplete help.
Looking Inside Applications
TestComplete’s Object Browser shows a lot of detail about applications running in the operating system and their windows and controls. All of the displayed methods, properties and actions can be used in your tests.
By default, the processes and windows only contain methods and properties provided by TestComplete. You can use them to test your application via the GUI, that is, to simulate keystrokes and mouse actions over windows and controls and to check certain windows’ attributes (like style, text and visibility).
This may be enough to create simple tests, but quite often, testing routines need access to those methods and properties that are provided by the tested application. In other words, they require access to the objects, methods and properties provided by the programming libraries that were used to create the application (WinForms, MFC, VCL, SWT, AWT and others).
If applications test themselves using their own code, then access to the applications’ internal objects is usually not a problem. However, even if applications are tested externally (for instance, with TestComplete scripts), there is no reason to use a simple GUI-test. Where possible, tested applications should be Open Applications, that is, they should provide access to their internal objects, methods and properties.
.NET, Java, Visual Basic, WPF and Java applications are “opened” by special plug-ins. All you need is to install these plug-ins in TestComplete. Visual C++, Delphi and C++Builder applications need to be recompiled in a special way to become “Open”. Compiling the application as an Open Application is fairly simple. Typically, it requires compiling the application with debug information and including one or two special units in your Visual C++, Delphi or C++Builder project. TestComplete has an exclusive technology called Debug Info Agent™ that works with tests to access practically all internal elements of the application under test, even private properties. For detailed information on Open Applications and on creating them, see the Open Applications topic in TestComplete help.
Once your application is “open” look at it through the Object Browser. You will see that making the application “Open” has multiplied the access to application objects for your test code. You can test much closer to the design level, and much more conveniently. Depending on the level of “openness”, you can use public, protected and even private methods, fields and properties in your tests.
TestComplete also includes two special plug-ins that provide deeper access to applications’ internals in comparison to the default access. One of these plug-ins, UI Automation Support, retrieves window properties provided by Microsoft UI Automation Framework. Another special plug-in, MSAA Open Applications, exposes methods and properties of windows that implement the IAccessible interface. This lets you work with windows of Sybase PowerBuilder, Microsoft Access and Visual FoxPro applications. You can see the objects, methods and properties, exposed by these plug-ins, in the Object Browser panel.
Testing Through Application Code
TestComplete’s services are provided through an OLE server. The entire user interface is simply a client of this server. By linking in just one file, an application can put itself in the place of the TestComplete user interface and run the OLE server directly, for whatever purpose. We call this a Connected Application.
The most common thing a Connected Application will do is run tests in its own source code (see Self-Testing Applications in TestComplete help). This is usually the easiest way to do unit tests (see Testing With TestComplete in TestComplete help).
Connected Applications can also be used to run tests on other applications. This way of testing provides more control over test conditions, since the TestComplete engine is commanded from source code rather than the user interface. For instance, you might want to run a specific series of tests at a given time, and which tests are to be run would depend on the conditions at that time. All of these can be done from a rather simple Connected Application.
Also, using Connected Applications simplifies the test creation because it is convenient to write test code in your normal programming language and use the preferred IDE for debugging.
Of course, application code in a Connected Application still has access to all of the objects a script uses. These are all OLE objects, and the needed interface is in the file that you link to.
The following figure explains the relations between TestComplete and other applications (Open, Connected and General applications):

Creating a Project
Projects contain all of the information about one or more applications that you test as well as data, scripts, a baseline copy of files and images and other information needed to perform the test. For a complex application you may choose to devote a project to just one part of the application, and other projects to other parts (normally, modules).
Note: We will illustrate each step of this Getting Started section with the Orders sample application, which is installed in the \Samples\Open Apps\OrdersDemo folder.
Please compile this application before you proceed with Getting Started.
If you have any problems compiling the application, you can use the compiled executable that resides in the \Samples\Open Apps\OrdersDemo folder.
To create a new test project:
• Select File | New | New Project from TestComplete’s main menu. This will call the Create New Project dialog where you can specify the project name, location, template, scripting language and the name and location of the project suite.

• Enter Orders as the project name and OrdersSuite as the project suite name. TestComplete will automatically generate the project path and display it in the Actual location field. Note that if the path is too long, TestComplete will shorten it by replacing some part of it with ellipsis. To view the complete path, move the mouse pointer over the Actual location field.
The project folder is used to store all information generated for or by the project -- scripts, results log, stores, and so on. You can change the project’s folder in the Location box. In our example we will keep the folder name unchanged.
• If you are have a project suite open in TestComplete, select the Create a new project suite check box (we will add the Orders project to the new suite).
• Then specify the project language, say VBScript.
Note: TestComplete is equally oriented to VBScript, JScript, DelphiScript, C++Script and C#Script, therefore it allows you to select the language you know. You will be able to use all of TestComplete’s features regardless of the language you choose. However, due to the fact that languages have different syntax and their script instructions are executed by different scripting engines, there are some exceptions (see Supported Scripting Languages - Peculiarities of Usage in TestComplete help). For more information on choosing the language, see Selecting the Scripting Language in TestComplete help.
We would like to also note that the scripting language does not depend on your tested application’s programming language. For instance, you can use JScript to test Visual C++ applications, or VBScript to test Delphi programs. There is one recommendation: if you plan to create a Connected or Self-Testing Application, you should select the language that matches the development tool that the application was created in. For example, if you use Visual C++ or C++Builder, you should select C++Script; if you use Visual Basic, select VBScript, and so forth. This will make it easier to import recorded scripts to Connected and Self-Testing Applications.
After specifying the project name, location and scripting language, you can specify the project template. Project templates define which project items your project will contain. The set of project items determines what testing actions a project can perform. For instance, using the Low-Level Procedures Collection project item you will be able to run low-level procedures and using the Events project item you will be able to handle events.
The template specifies which of the project items will be included in your project by default. You can modify the set of enabled items using the Project Wizard that is shown after you click OK in the Create New Project dialog. You can also add the desired items to your project at any time. For more information on this, see Adding and Removing Project Items and Their Child Elements in TestComplete help.
• In the Create New Project dialog, select any template in the Templates box and click OK. TestComplete will open the Project Wizard where you can modify the project items to be included in the project.
• Select any template in the Templates box.
• Click OK in the Create New Project dialog. TestComplete will open the Project Wizard where you can modify the project items to be included in the project.

Now let’s select project items for our sample project. It will contain scripts, a list of tested applications and stores:
• Uncheck all the items in the Project Items list except for the Script item (as for tested applications, we will add them later to demonstrate how to add items to existing projects. Stores will be added during the script recording). Note that the Events item can only be unchecked if the Insert general events in new projects option is disabled. You can do this in the Events Options dialog before creating the project (to display the dialog, choose Tools | Options from TestComplete's main menu and then select Engines | Events in the ensuing Options dialog).
• Click Next to switch to the next page of the Project Wizard.
• Switch to the Script page. Here you can add one or more script units to your project. By default, TestComplete creates one unit named Unit1. This is enough for our sample project and there is no need to create more units.
• Press Finish in the Project Wizard. TestComplete will create a new project file, Orders.mds, with the Unit1 script unit and display the project’s contents in the Project Explorer panel.
Defining Applications to Test
Each project may have a list of tested applications. This is a way for you to keep track of which applications the project deals with and how they are configured for testing. It also allows TestComplete to launch all applications in the list or only those applications that are enabled to be launched manually via the context menu, or from a script. Of course, since projects are independent from one another, any application may be in more than one project’s list.
To add a Win32 tested application to our project, we first need to add the Win32 Tested Applications project item. To do this:
• Right-click the project node in the Project Explorer panel and select Add | New Item from the context menu.

This will call the Create Project Item dialog.

• In the dialog:
 Select the Win32 Tested Applications item.
 Keep the value displayed in the Location box unchanged (this value specifies the folder where the .tcTAs file contains the tested application’s settings).
 Press OK.
TestComplete will add the Win32 Tested Application project item, TestedApps, to your project and show it in the Project Explorer panel.
Now we can add our sample application to the tested applications list:
• Right-click the TestedApps node in the Project Explorer panel.
• Choose Add | New Item from the context menu. The standard Open File dialog will appear.
• Locate Orders.exe using this dialog and then click Open.
The application executable and the source code are in the \Samples\Open Apps\OrdersDemo folder.
In this tutorial, we use the Orders application compiled with Visual C#. So, if you installed TestComplete to the default location, the path to Orders.exe looks like this: C:\Program Files\Automated QA\TestComplete 6\Samples\Open Apps\OrderDemo\C#\bin\Debug\Orders.exe.
Now, the sample application is in the list and we can specify command-line arguments for it:
• Double-click the TestedApps | Orders node in the Project Explorer panel. TestComplete will show the available settings in the TestedApps editor.

• Now we should select the application’s run mode. A tested application can be launched in several modes: Simple, RunAs, Debug or Profile. The Simple mode is similar to launching the application from Windows Explorer or the command line window. Using the RunAs mode you can launch the application under a different user account than TestComplete is currently running under. Debug mode is similar to Simple, but TestComplete will act as a debugger for the application and will report information about events and errors that occur during the application run. Finally, Profile mode is used to debug and profile the application with AQtime. For more information on these modes, see Run Modes in TestComplete help.
For our sample application we will use Simple run mode. This mode is used by default for tested applications. Look at the Run Mode column and make sure the Simple mode is selected:

• Now we will change the application’s command line. To do this, press the ellipsis button within the Parameters column. This will call the Parameters dialog.
• Type -NOTOPENAPP or /NOTOPENAPP in the Command-line parameters edit box. We will explain this command-line argument later (see Exploring the Application in the Object Browser).

Press OK to close the dialog.

• Save your changes by selecting File | Save from TestComplete’s main menu.
As you can see, all application parameters (command line, work folder and so on) can be set in one place.
As stated above, one purpose of the tested applications list is to provide you with a way to launch all applications before you start recording a script. Of course, you can record the launch of an application, but that is inefficient for a number of reasons: the manner of launching from a desktop is cumbersome and/or fragile (a shortcut icon can be hidden), providing special parameters is impossible, and so forth.
It is easier and more adaptable to have all the launch specifications you may need in the list, and to uncheck anything that is not needed for the current run (in the Launch column). Then you choose Run Selected or Run All from the context menu and wait until the application’s main window appears on screen.
In the next steps we will explore which internal objects, methods and properties of the tested application are available to TestComplete and then will record user actions over the application.
Exploring the Application in the Object Browser
Before recording or running a script, you can explore what properties, fields, methods and events of your application’s object TestComplete has access to. As the Introduction states, TestComplete can access almost all application objects, methods and properties, even if they are not part of the application UI. The Object Browser panel shows you exactly what is available to your scripts:

The tree view on the left contains a list of processes that are currently running in the operating system and their windows. All processes are direct children of System (the Sys object in scripts), and windows are children of the process that opened them. In TestComplete terms, processes and windows are objects, and this is how they are represented in scripts (see How TestComplete Recognizes Process, Windows and Controls in TestComplete help).
The right pane displays the selected object’s methods and properties that are available to scripts.
If you use Windows Vista or Windows Server 2008 and you do not see an existing process in the Object Browser, most likely the process and TestComplete have different permissions. In order for TestComplete to be able to test applications under Windows Vista and Windows Server 2008, it must have the same permissions as the application. See Testing Applications With TestComplete Under Windows Vista and Windows Server 2008 in TestComplete help.
Now we can explore our sample application.
• To launch the application, right-click the application node (Orders) in the Project Explorer panel and select Run from the context menu. The application node is a child node of the TestedApps node.
Wait until the application’s main window appears:

• Find the application in the Object Browser tree view. If the tree contains too many processes, you can filter it to only view the tested applications. To do this, click Show Tested Applications Only on the Object Browser’s toolbar.
• Expand the application node and look at its windows and their properties. The right pane displays properties and methods that can be used in scripts (see the image below).
Note: The following image displays the properties, methods and objects of the Orders application created in C#. The properties, methods, window class names and the whole object structure that you see in the Object Browser on your computer may differ from what is displayed in the image. The information you see depends on the development tool, which you used to compile the tested application. For instance, the objects’, methods’ and properties’ names as well as the object structure of Visual C++ 6 applications differ from those of .NET applications.

Currently, the windows of the Orders application contain only TestComplete-defined properties, not those defined in the application source. This may be enough to test the user interface of some Windows applications, since TestComplete supports almost all standard Windows controls: list views, combo boxes, tree views, and so on.
If you want to dig deeper into the application, you must compile it as an Open Application. In this case, objects, methods and properties defined in the source code become available to TestComplete scripts. Open Applications can be created in any supported compiler. For some compilers, there is more than one way to create an Open Application. Each variant provides a different degree of openness. Please read Open Applications in TestComplete help for more information.
The Orders application is already compiled as an Open Application. It provides maximum openness, that is, it makes all public, published and protected elements (with some restrictions) accessible to TestComplete and script routines. Currently, TestComplete does not have access to internal properties and methods of the Orders application because we have specified the -NotOpenApp command-line argument for the application. Let’s change the command line:
• Close the Orders application.
• Double-click the application node in the Project Explorer panel. TestComplete will show the list of the tested applications in the Workspace panel.
• Press the ellipsis button within the Parameters column.
• In the resulting Parameters dialog, remove -NotOpenApp from the Command-line parameters edit box. Press OK to close the dialog.

• Save the changes by selecting File | Save from TestComplete’s main menu (this menu item can be disabled, if you accidentally selected a project item other than TestedApps in the Project Explorer).
• Right-click the application’s node in the Project Explorer panel and choose Run from the context menu. TestComplete will launch the Orders application and you will be able to explore the application’s objects in the Object Browser:

The Object Browser now displays a special icon ( ) for the Orders process. The icon indicates that TestComplete recognizes the Orders application as an Open Application.
The Object tree shows a list of internal application’s objects. The image above shows the objects of the Orders application compiled with Microsoft Visual C#. These objects are addressed with the syntax WinFormsObject("Object_Name"). WinFormsObject is the method that is used to address objects in .NET applications that were created with Microsoft’s Windows Forms library. If you compile the Orders application with another compiler, TestComplete will address the objects using another method: VBObject, VCLObject, SwingObject, and so on.
If the TestComplete 3 Compatibility plug-in is installed, TestComplete emulates the functionality of the previous versions of TestComplete and will address objects by their names: MainForm, ImageList1, and so forth. Since version 4, TestComplete uses other principles for addressing objects than the previous versions used. The image above demonstrates when the compatibility plug-in is not installed. In this topic and other topics of the Getting Started section, we will assume that the compatibility plug-in is not installed.
The right portion of the Object Browser displays properties and methods of the object selected in the object tree. The method and property lists include methods and properties defined in the application’s source code as well as methods and properties introduced by TestComplete. Note that some methods and properties are unavailable to TestComplete (see Object Properties, Fields and Methods That Are Unavailable to TestComplete in TestComplete help). Also, protected and private properties are hidden from the panel by default. For more information on this, see Access to Properties in TestComplete help.
Now, let’s change the caption of the application’s main form. To do this:
• Locate the form in the Objects tree.
• Switch to the right pane and finding the Caption property.
• Specify the new caption in the Caption property and confirm the change by pressing ENTER.
The form caption will be changed. You have literally changed Orders’ internal data, and the next screen update reflects the new data.
Note: For Visual C++ applications this procedure cannot be executed from the Browser, since Visual C++ applications do not have properties (they use fields and methods). In this case, you can change the form’s title by calling the appropriate Visual C++ method.
Note that some methods and properties remain unavailable to TestComplete even if the application is compiled as an Open Application. There are a number of reasons for this. Typically, it occurs with non-OLE-compatible properties, with methods containing non-OLE-compatible parameters or return values. See Object Properties Fields and Methods That Are Unavailable to TestComplete in TestComplete help for more information.
Some Read/Write properties are displayed as Read-Only ( ) or Write-Only ( ). These properties will be Read-Only or Write-Only in scripts. Usually, this means that the property value is not read or set in the application’s source code, that is, the application does not call the “get” or “set” function, so the compiler does not include the function in the application’s binary code.
The following properties of Visual Basic applications are not accessible to interprocess calls:
• Icon
• Image
• MouseIcon
• Palette
• Picture
As a result, if you try to view these properties via the Object Browser, an error will occur in the Visual Basic application you are exploring.
One last feature of the Browser is that it lets you explore the internal structure of COM objects if you know their class or program identifiers, for instance Word.Application or Scripting.FileSystemObject. Try the following:
• In the tree view select the root node (Sys).
• Find the OleObject property in the right pane.
• Click the Params button. This will call a small dialog.
• Assuming Word is installed on your machine (open or not), enter its program identifier, Word.Application, in the dialog and press OK. (Note that you can use the class id as well as the program id).

• Wait until the OleObject property displays IDispatch for a value. This means you supplied the correct identifier and TestComplete successfully obtained a reference to the desired object (IDispatch indicates that the value is an object).
The OleObject property acts as an indexed property that uses program (or class) identifiers as parameters. Supply a valid index, and a valid value will be created for it (the IDispatch interface that is now available).
• The new value (IDispatch), in turn, displays its own ellipsis button. Press it to explore the desired COM object.
Creating Tests
General Notes
Before you create a new test, you should plan it:
• Define the test goal (decide which application functionality to be tested).
The clearer the goal and the simpler the test, the better. Do not create tests that will test various aspects of the application’s behavior at one run. It is better to create a simple test that is aimed at one objective only. Such tests are easier to create and maintain. Once you create several simple tests, you can always organize them into a larger test.
• Plan testing steps (decide which actions the test will perform).
The testing steps depend on the test purpose and the nature of the application under test. For instance, testing of a Web server may require simulating an extensive load, which requires the recording and playback of HTTP traffic to that server, while testing of an image editor may need the recording and playback of mouse movements and presses and releases of mouse buttons. TestComplete lets you simulate these and other actions over the applications under test.
Testing steps may include actions that prepare the application for the test (that is, they put the application to some initial state).
Also, testing steps may feed corresponding input to the application.
• Check test results (decide how to determine that the test passed successfully or failed).
After the testing actions are finished, the test should check the results against the expected output and decide whether the test was successful or not. Typically, after the application performed some actions, something changed in that application: data in an application window can be rearranged, a new window may be created, a file can be created on or deleted from your hard disk, and so on. You should determine what facts will be used as the fail (or success) criteria.
• Logging the result (determine how you will log the test result).
The test results can be logged in different ways, for instance, your test scripts can save the full test results to a file or show an on screen image notifying you that the test run is over.
TestComplete tracks all simulated actions during the test run and saves the information on these actions to the test log. Of course, you can post custom messages, image, files or file links to the log. The messages can be organized into folders and each message may use specific font and background settings to display. The results can be exported to a file, compressed and sent via e-mail to your co-workers. You can even create a bug report in an issue-tracking system directly from test results shown in the log. See Test Log for more information.

After you have planned your test, you can create it. The basic test sequence includes the following steps:
1. Define expected output.
2. Feed corresponding input.
3. Gather output.
4. Compare to expected output.
5. Call for attention if the comparison fails.
These items can be divided into a sequence of smaller substeps, each of which will perform a smaller task. We call these substeps test items.
A TestComplete project holds one or more project items. Some project items (for instance, Script) or their child elements (script routines) may be used as a source of tests. That is, a project item or its child element may be used as a test item - it can be “executed” as a test or a subtest. Projects themselves can also be used as test items: this happens when you create tests for project suites.
What actually happens when you execute a test item is determined by the properties of that test item. For instance, if a test item executes a script routine, TestComplete will run this routine; if a test item executes the Script project item, TestComplete will execute the script routine that is specified by the Main Routine property of that project item. If you command TestComplete to execute a project, TestComplete will perform the test item defined by the project’s properties.
To create a test in TestComplete:
• Define the test purpose.
• Create source elements for test items (for instance, write or record a script, create a manual or unit test, record a low-level procedure, etc.). The test items created depend on your application and the test purpose.
• Specify the execution order of test items.
• Write a script that will check and log the test result (if necessary). This item is optional, because some test items (for example, low-level procedures) automatically post messages about their execution to the log. TestComplete provides various ways that let you decide whether the test passed successfully. These include special functions for comparing images, files and collections of object properties, script methods and properties that let you check whether a window is visible or hidden, capture the window image, and so on.
Creating a Test for the Orders Application
The sample Orders application maintains a list of orders. Suppose we need to test whether the application generates the customer list correctly. In this case --
• Test purpose: The test should check whether the Orders application generates the customer list properly.
• Testing steps: To generate the customer list, the user should select the Report | Generate customer list item from the main menu of the Orders application. One way to create a test that checks the customer list is to write or record a script or record a low-level procedure that will simulate the desired user actions. You may even create several scripts (or low-level procedures): one of them may call a form with a button on it, another - simulates user actions over the form, and so forth.
When the user presses the button to generate the customer list, the application calls the routine that generates the list. A possible alternative to simulating user actions is to call the application’s routine that generates the list. This requires TestComplete to have access to the internal application’s objects, methods and properties, so that you can call this routine directly from your scripts. In order for TestComplete to have access to application internals, the application under test must be compiled as an Open Application.
Though our sample application is compiled as an Open Application, we will follow the first approach: we will create a script that will simulate user actions.
• Checking and logging the test result: If the customer list has been generated successfully, the Orders application creates a file that holds the customer names. To check whether the list was generated successfully, our test can check whether the file exists and then compare the generated file with the base-line copy stored earlier. We will write script instructions that will perform the described checking and post an error message (if necessary) to the test log.
Currently, our sample project does not include script routines, low-level procedures or other project items that can be used as test items. Also, the test item sequence is not specified. In the next steps we will record a script routine and then use it as a test item.
Recording a Test Script
This topic provides general information about the recording capabilities offered by TestComplete and describes how to record a test script for the Orders application.
Requirement: if you use a computer that has several processors or a multiple-core processor (for example, dual-core CPU) and has Windows XP Service Pack 2, then you must install the Windows update #896256 in order for TestComplete to be able to record user actions correctly. The update is available on Microsoft’s web site:
http://support.microsoft.com/kb/896256
Without this update, TestComplete will record user actions incorrectly. For instance, it may have an invalid order of keypresses or record double-clicks instead of the drag or click events.
Recording in TestComplete – General Information
With TestComplete you can record scripts, low-level procedures and HTTP traffic. To start the recording, select Script | Record from TestComplete’s main menu or press Record on the Test Engine toolbar. This will switch TestComplete to the recording mode and display the Recording toolbar on the screen:

The toolbar contains items that let you pause and stop recording, specify the recorded item (script code, low-level procedure or HTTP traffic) and perform additional actions during the recording. For instance, using the Run Tested Application item you can launch a tested application and by using the Add Checkpoint From List button you can create checkpoints during the recording. You can also insert comments or additional code when recording scripts. To do this, press Add Text To Script. We recommend that you comment your script as you record it, since this is when your ideas are the clearest to you.
By default, once you initiate recording, TestComplete automatically starts recording a script. To record a low-level procedure, use the Record Low-Level Procedure (screen coordinates) or Record Low-Level Procedure (window coordinates) button. To record HTTP traffic, use the Record an HTTP Task button. (See Creating and Recording Low-Level Procedures and Traffic Recording in TestComplete help).
TestComplete records scripts as a series of instructions in one of the supported scripting languages: VBScript, JScript, DelphiScript, C++Script or C#Script. You can use the Code Editor at any time to modify recorded scripts and to add specific non-recordable commands.
By default, TestComplete always creates a new script routine before recording. You can also record script code into the current position of the Code Editor. To do this, disable the Always start a new script option. To change the option, choose Tools | Options from TestComplete’s main menu and then select Engines | Recording in the ensuing Options dialog. This will display the Recording options on the right of the Options dialog. When the Always start a new script option is disabled, the way the script is recorded depends on the insertion point position within the Code Editor window.If the insertion point is somewhere inside a script routine (procedure or function), the script recorder will insert the recorder code into this position. If the insertion point is outside an existing routine, the script recorder will create a new routine before recording.
TestComplete automatically creates a name for the new script routine. The name looks like TestN, where N is a number (1, 2, 3, 4 and so on). If the script unit does not contain any routines, TestComplete uses the name Test1. If the Test1 routine exists, it uses the name Test2 and so on. That is, TestComplete automatically chooses the routine name that does not coincide with the names of other routines in the unit. However, this is possible only if the routines in the unit do not have syntax errors. Else, TestComplete will always name the new script routine Test1.
To avoid making the script too dependent on the precise screen layout, and to keep it readable and reasonably short, TestComplete, by default, only records keyboard and mouse events that affect Windows controls. TestComplete does not, for instance, record the precise path of the mouse between clicks in different places, or the time elapsed between each keystroke. However, full-detail recording can be activated by simply using the low-level procedures.
Also by default, TestComplete does not record the delay between user actions. This makes the script faster and decreases its overall size. If time periods are critical, enable the Real-Time Mode option before recording (you can change this option in the same Recording Options dialog, in which you modify the Always start a new script setting described above).When the Real-Time Mode option is enabled, TestComplete records the delay between user actions. As a result, you will get a larger script, but it will be executed at the same speed as it was recorded. You can of course remove the needless delay commands, and modify others to make the script run faster. For further information on options that affect recording, see Recording Options Dialog in TestComplete help.
When you start script recording, TestComplete automatically turns off the state of the CAPS LOCK key. The same operation is performed when starting the test run. These actions ensure that TestComplete will correctly simulate keystrokes.
To record object names, TestComplete uses the process, window and control names that are displayed in the Object Browser panel. These names can sometimes be too long and hard to understand. However, you can assign a custom name to an object. If you assign a custom name, the recorded script will use the mapped name to address the object, so, you will have clearer and more readable code. For more information, see Name Mapping, Adding Name Mapping Items and Name Mapping and Script Recording in TestComplete help.
You can use keyboard shortcuts to start or finish recording, and to control the recording process and playback. Shortcuts free you from having to switch to the TestComplete window every time you want to start or stop recording. To customize the shortcuts, use the Shortcut Options dialog.
For more information on script recording and on recording peculiarities, see the Recording in TestComplete section in TestComplete help.
Recording a Script for the Orders Application
We are now ready to record a script for the Orders application. Let’s record this script using a usual (non-open) application:
• Double-click the Orders | TestedApps project item in the Project Explorer panel. TestComplete will show the list of tested applications in the Workspace. Press the ellipsis button in the Parameters cell and specify -NotOpenApp or /NotOpenApp in the Command line parameters field of the resulting dialog. Close the dialog and return to the TestedApps editor.
Select File | Save All from TestComplete’s main menu to save the changes.
• Select Script | Record from the main menu to start recording. Wait until the Recording toolbar appears.
• Press the down arrow of the Run Tested Applications button and select Orders from the drop-down list:

When you launch tested applications this way, TestComplete automatically inserts a method call, which is used to launch a tested application, into the recorded script (you will see the call in the next step, when we explore the recorded code).
• Wait until the application starts and the application’s main window is shown:

• Switch to the Orders application and select File | Open from its main menu. This will bring up the standard Open File dialog.
• In the dialog, open the MyTable.tbl file that resides in the \Samples\Open Apps\OrdersDemo folder.
It is recommended to type the fully-qualified file name into the File name box of the Open File dialog. Typing instead of using the mouse will help you avoid problems if the Open File dialog displays a different initial folder when the script is played back later.
After you specified the file, the Orders application will load data from it and display this data in the main window.

• Select Samuel Clemens in the list of orders.
• Now we will create an image checkpoint --
 Select Create Region Checkpoint from the Recording toolbar.

This will invoke the Create Region Checkpoint dialog:

 Move the Create Region Checkpoint dialog so that it does not overlap the main window of the Orders application.
 Click the icon in the dialog, keep the mouse button pressed and move the cursor to the Orders toolbar. As you move the mouse, TestComplete highlights the window’s control under the cursor using a red frame.
 When the Orders toolbar is highlighted, release the mouse button. TestComplete will display the scripting name of the toolbar in the Object box of the Create Region Checkpoint dialog.
 Store the toolbar’s image in the Regions collection of the Stores project item:
o Select Create new item in stores. This will specify that TestComplete should add the toolbar’s image to the Regions collection as a new element.
o Type Toolbar into the Stores picture name box. This box specifies the name of the Stores element to be created.
o Leave other parameters (Tolerance, Transparent, Include mouse point and Report difference) unchanged. For more information on them, see Create Region Checkpoint Dialog in TestComplete help.

o Press OK. TestComplete will display the dialog asking you to add the Stores item to your project.
 After you add the image, TestComplete will generate script code for the image comparison and display this code in the Add Text To Script dialog:
Note: The following image displays the comparison instructions in VBScript. The syntax of the instructions you see in the Add Text To Script dialog on your computer may differ from what is shown on the image. The actual code you see depends on the scripting language you have selected for your TestComplete project on the Creating a Project step.

 Press Add to close this dialog. TestComplete will insert the comparison instructions into the script code.
• After closing the Add Text to Script dialog, we are back to the Orders application. Click the title of the application’s main window, to activate the window.
• Move the mouse cursor to the Orders toolbar and press Edit order. This will call the Edit Order dialog.
• In the dialog, select FamilyAlbum from the Product dropdown list.
• Select the value in the Card Nr edit field by dragging the mouse and then enter 123123123123 as a card number.
• Click OK to close the dialog.
• Now you can export the customer list to a file. To do this:
 Select Report | Generate customer list from the main menu of the Orders application. Orders will display the Save File dialog.
 Enter C:\CustomerList.txt into the File name edit box of the Save File dialog.
 Click OK to close the dialog.
The application will save the customer list into the specified file.
• Close the Orders window by clicking the X button on the window's caption bar. This will display the dialog asking if you want to save changes. Press No. Orders will close.
• Press Stop on the Recording toolbar to halt the recording.
In the next step we will analyze the recorded instructions.
Analyzing the Recorded Script
The recorded script is added to and displayed in the Code Editor. Each script appears as a procedure coded in VBScript, JScript, DelphiScript, C++Script or C#Script. More information about writing scripts is available in the next topic. This topic only explains the recorded instructions.
To open the Code Editor panel, right-click the Script | Unit1 node in the Project Explorer panel and then choose Edit from the context menu, or simply double-click the Script | Unit1 node. TestComplete will display the code of Unit1 in the Workspace panel.
The recorded script code is similar to the code below. Your actual script may differ from this one. For example, it may have other class names or window indexes if you have recorded the script on a Visual C++ or Delphi application.
[VBScript]
Sub Test1
Dim p1
Dim w1
Dim w2
Dim w3
Dim w4
TestedApps.Orders.Run
Set p1 = Sys.Process("Orders")
Set w1 = p1.Window("WindowsForms10.Window.8.app3", "*")
Call w1.MainMenu.Click("File|Open...")
Set w2 = p1.Window("#32770", "Open")
Call w2.Window("ComboBoxEx32").Window("ComboBox").Window("Edit").Keys("C:\Program Files\Automated QA\TestComplete 6\Samples\Open Apps\OrdersDemo\MyTable.tbl")
w2.Window("Button", "&Open").ClickButton
Call w1.Window("WindowsForms10.SysListView32.app3").ClickItem("Samuel Clemens", 0)
If (Not Regions.Compare(Sys.Process("Orders").Window("WindowsForms10.Window.8.app3", "*").Window("WindowsForms10.ToolbarWindow32.app3"), "Toolbar", False, False, True, 0)) Then
Call Log.Error("The regions are not identical.")
End If
Call w1.Click(195, 10)
Call w1.Window("WindowsForms10.ToolbarWindow32.app3").ClickItem(5, False)
Set w2 = p1.Window("WindowsForms10.Window.8.app3", "Order")
Set w3 = w2.Window("WindowsForms10.Window.8.app3")
Call w3.Window("WindowsForms10.COMBOBOX.app3").ClickItem("FamilyAlbum")
Set w4 = w3.Window("WindowsForms10.EDIT.app3", "123456789012")
Call w4.Drag(82, 7, -97, 2)
Call w4.Keys("123123123123")
w2.Window("WindowsForms10.BUTTON.app3", "OK").ClickButton
Call w1.MainMenu.Click("Report|Generate customer list...")
Set w2 = p1.Window("#32770", "Save As")
Call w2.Window("ComboBoxEx32").Window("ComboBox").Window("Edit").Keys("c:\CustomerList.txt")
w2.Window("Button", "&Save").ClickButton
w1.Close
p1.Window("#32770", "Confirmation").Window("Button", "&No").ClickButton
End Sub

[JScript]
function Test1()
{
var p1;
var w1;
var w2;
var w3;
var w4;
TestedApps.Orders.Run();
p1 = Sys.Process("Orders");
w1 = p1.Window("WindowsForms10.Window.8.app3", "*");
w1.MainMenu.Click("File|Open...");
w2 = p1.Window("#32770", "Open");
w2.Window("ComboBoxEx32").Window("ComboBox").Window("Edit").Keys("C:\\Program Files\\Automated QA\\TestComplete 6\\Samples\\Open Apps\\OrdersDemo\\MyTable.tbl");
w2.Window("Button", "&Open").ClickButton();
w1.Window("WindowsForms10.SysListView32.app3").ClickItem("Samuel Clemens", 0);
if(!Regions.Compare(Sys.Process("Orders").Window("WindowsForms10.Window.8.app3", "*").Window("WindowsForms10.ToolbarWindow32.app3"), "Toolbar", false, false, true, 0))
Log.Error("The regions are not identical.");
w1.Click(195, 10);
w1.Window("WindowsForms10.ToolbarWindow32.app3").ClickItem(5, false);
w2 = p1.Window("WindowsForms10.Window.8.app3", "Order");
w3 = w2.Window("WindowsForms10.Window.8.app3");
w3.Window("WindowsForms10.COMBOBOX.app3").ClickItem("FamilyAlbum");
w4 = w3.Window("WindowsForms10.EDIT.app3", "123456789012");
w4.Drag(92, 12, -112, 0);
w4.Keys("123123123123");
w2.Window("WindowsForms10.BUTTON.app3", "OK").ClickButton();
w1.MainMenu.Click("Report|Generate customer list...");
w2 = p1.Window("#32770", "Save As");
w2.Window("ComboBoxEx32").Window("ComboBox").Window("Edit").Keys("c:\\CustomerList.txt");
w2.Window("Button", "&Save").ClickButton();
w1.Close();
p1.Window("#32770", "Confirmation").Window("Button", "&No").ClickButton();
}

[DelphiScript]
procedure Test1;
var p1 : OleVariant;
var w1 : OleVariant;
var w2 : OleVariant;
var w3 : OleVariant;
var w4 : OleVariant;
begin
TestedApps.Orders.Run;
p1 := Sys.Process('Orders');
w1 := p1.Window('WindowsForms10.Window.8.app3', '*');
w1.MainMenu.Click('File|Open...');
w2 := p1.Window('#32770', 'Open');
w2.Window('ComboBoxEx32').Window('ComboBox').Window('Edit').Keys('C:\Program Files\Automated QA\TestComplete 6\Samples\Open Apps\OrdersDemo\MyTable.tbl');
w2.Window('Button', '&Open').ClickButton;
w1.Window('WindowsForms10.SysListView32.app3').ClickItem('Samuel Clemens', 0);
if not Regions.Compare(Sys.Process('Orders').Window('WindowsForms10.Window.8.app3', '*').Window('WindowsForms10.ToolbarWindow32.app3'), 'Toolbar', false, false, true, 0) then
Log.Error('The regions are not identical.');
w1.Click(195, 10);
w1.Window('WindowsForms10.ToolbarWindow32.app3').ClickItem(5, false);
w2 := p1.Window('WindowsForms10.Window.8.app3', 'Order');
w3 := w2.Window('WindowsForms10.Window.8.app3');
w3.Window('WindowsForms10.COMBOBOX.app3').ClickItem('FamilyAlbum');
w4 := w3.Window('WindowsForms10.EDIT.app3', '123456789012');
w4.Drag(81, 10, -133, -2);
w4.Keys('123123123123');
w2.Window('WindowsForms10.BUTTON.app3', 'OK').ClickButton;
w1.MainMenu.Click('Report|Generate customer list...');
w2 := p1.Window('#32770', 'Save As');
w2.Window('ComboBoxEx32').Window('ComboBox').Window('Edit').Keys('C:\CustomerList.txt');
w2.Window('Button', '&Save').ClickButton;
w1.Close;
p1.Window('#32770', 'Confirmation').Window('Button', '&No').ClickButton;
end;

[C++Script, C#Script]
function Test1()
{
var p1;
var w1;
var w2;
var w3;
var w4;
TestedApps["Orders"]["Run"]();
p1 = Sys["Process"]("Orders");
w1 = p1["Window"]("WindowsForms10.Window.8.app3", "*");
w1["MainMenu"]["Click"]("File|Open...");
w2 = p1["Window"]("#32770", "Open");
w2["Window"]("ComboBoxEx32")["Window"]("ComboBox")["Window"]("Edit")["Keys"]("C:\\Program Files\\Automated QA\\TestComplete 6\\Samples\\Open Apps\\OrdersDemo\\MyTable.tbl");
w2["Window"]("Button", "&Open")["ClickButton"]();
w1["Window"]("WindowsForms10.SysListView32.app3")["ClickItem"]("Samuel Clemens", 0);
if(!Regions["Compare"](Sys["Process"]("Orders")["Window"]("WindowsForms10.Window.8.app3", "*")["Window"]("WindowsForms10.ToolbarWindow32.app3"), "Toolbar", false, false, true, 0))
Log["Error"]("The regions are not identical.");
w1["Click"](195, 10);
w1["Window"]("WindowsForms10.ToolbarWindow32.app3")["ClickItem"](5, false);
w2 = p1["Window"]("WindowsForms10.Window.8.app3", "Order");
w3 = w2["Window"]("WindowsForms10.Window.8.app3");
w3["Window"]("WindowsForms10.COMBOBOX.app3")["ClickItem"]("FamilyAlbum");
w4 = w3["Window"]("WindowsForms10.EDIT.app3", "123456789012");
w4["Drag"](83, 8, -167, -6);
w4["Keys"]("123123123123");
w2["Window"]("WindowsForms10.BUTTON.app3", "OK")["ClickButton"]();
w1["MainMenu"]["Click"]("Report|Generate customer list...");
w2 = p1["Window"]("#32770", "Save As");
w2["Window"]("ComboBoxEx32")["Window"]("ComboBox")["Window"]("Edit")["Keys"]("C:\\CustomerList.txt");
w2["Window"]("Button", "&Save")["ClickButton"]();
w1["Close"]();
p1["Window"]("#32770", "Confirmation")["Window"]("Button", "&No")["ClickButton"]();
}
The script starts with variable declarations. TestComplete automatically detects what objects (process, windows, controls, etc.) you recorded with user actions and defines the appropriate number of variables.
[VBScript]
Dim p1
Dim w1
Dim w2
Dim w3
Dim w4

[JScript]
var p1;
var w1;
var w2;
var w3;
var w4;

[DelphiScript]
var p1 : OleVariant;
var w1 : OleVariant;
var w2 : OleVariant;
var w3 : OleVariant;
var w4 : OleVariant;

[C++Script, C#Script]
var p1;
var w1;
var w2;
var w3;
var w4;
The variable declarations are followed by this line –
[VBScript]
TestedApps.Orders.Run

[JScript]
TestedApps.Orders.Run();

[DelphiScript]
TestedApps.Orders.Run;

[C++Script, C#Script]
TestedApps["Orders"]["Run"]();
This line launches the Orders application. TestComplete records the line since we launched the application from the Recording toolbar during the script recording. The TestedApps object provides a scripting interface to the applications added to the tested applications list. The applications are identified by their name in the list (in our case, the name is Orders). The Run method launches the application. For more information on launching tested applications, see Working With Tested Applications in Scripts.
A call to the Run method is followed by this line --
[VBScript]
Set p1 = Sys.Process("Orders.exe")

[JScript]
p1 = Sys.Process("Orders");

[DelphiScript]
p1 := Sys.Process('Orders');

[C++Script, C#Script]
p1 = Sys["Process"]("Orders");
This line calls the Process method of the Sys object. TestComplete provides special program objects to work with processes and windows from scripts. The Sys.Process(...) method returns the process object that represents the application (process) in scripts. This returned object is stored to the p1 variable that was defined at the beginning of our script routine.
The Process method is executed successfully only if the process (that is, the application) exists in the system. Otherwise, TestComplete will generate an error and post it to the test log.
If you want to check the existence of the process without posting an error message to the log, you can use the WaitProcess method of the Sys object. This method pauses the script execution until the specified process is created or until the specified timeout is reached. If the process does not exist, the method returns an empty stub object; it does not post an error message to the test log:
[VBScript]
...
' Wait for the process called MyApp for 3000 milliseconds
Set p = Sys.WaitProcess("MyApp", 3000)

' Check whether the process exists
If Not p.Exists Then
' The process does not exist
Else
' The process exists
End If
...

[JScript]
var p;
...
// Wait for the process called MyApp for 3000 milliseconds
p = Sys.WaitProcess("MyApp", 3000);

// Check whether the process exists
if (! p.Exists)
// The process does not exist
else
// The process exists
...

[DelphiScript]
var
p : OleVariant;
begin
...
// Wait for the process called MyApp for 3000 milliseconds
p := Sys.WaitProcess('MyApp', 3000);

// Check whether the process exists
if not p.Exists then
// The process does not exist
else
// The process exists
...
end;

[C++Script, C#Script]
var p;
...
// Wait for the process called MyApp for 3000 milliseconds
p = Sys["WaitProcess"]("MyApp", 3000);

// Check whether the process exists
if (! p["Exists"])
// The process does not exist
else
// The process exists
...
Objects that do not exist are always something to worry about with external scripts dealing with processes or windows. For instance, you may need to check whether a process exists to detemine whether you can continue testing or not. To perform this check, use the Exists property (this property belong to all scripting objects that correspond to processes, windows and controls):
[VBScript]
' Obtain the process
Set p2 = Sys.Process("MyProcess")

' Do something here

' Check whether the process exists
If p2.Exists Then
' Process exists
Else
' Process was closed
End If

[JScript]
// Obtain the process
p2 = Sys.Process("MyProcess");

// Do something here

// Check whether the process exists
if (p2.Exists)
// Process exists
else
// Process was closed

[DelphiScript]
// Obtain the process
p2 := Sys.Process('MyProcess');

// Do something here

// Check whether the process exists
if p2.Exists then
// Process exists
else
// Process was closed

[C++Script, C#Script]
// Obtain the process
p2 = Sys["Process"]("MyProcess");

// Do something here

// Check whether the process exists
if (p2["Exists"])
// Process exists
else
// Process was closed
Let’s return to the recorded code. The next method after Sys.Process is p1.Window(...) --
[VBScript]
Set w1 = p1.Window("WindowsForms10.Window.8.app3", "*")

[JScript]
w1 = p1.Window("WindowsForms10.Window.8.app3", "*");

[DelphiScript]
w1 := p1.Window('WindowsForms10.Window.8.app3', '*');

[C++Script, C#Script]
w1 = p1["Window"]("WindowsForms10.Window.8.app3", "*");
This is a method of the process object (p1). It returns the window object for a window created by the process. It uses the window class name, caption and window index (similar to z-order) as parameters. In our case, only the first two parameters are used; the third one is omitted: TestComplete may not record the index if the class name and caption are enough for window recognition.
If needed, you may map the “long” process and window names to a shorter and more readable string. See Name Mapping in TestComplete help.
As you can see, TestComplete recorded the * wildcard instead of the window caption. This was done to make the script more universal. The window caption is an unstable window attribute. It can be modified several times during the application run. Replacing the variable part of the window caption with wildcard characters (* and ?) guarantees that the script will work when the caption is changed.
You can use wildcards in the window class name as well. This is necessary for some MFC windows whose class name (like Afx:400000:823:10011:0:0) changes from one application run to another. TestComplete includes a special option that controls how the class names of MFC windows are recorded. This option is called Auto-correct Afx window classes. If this option is enabled, TestComplete automatically inserts wildcards in the class name during recording. If the option is disabled, the wildcards are not used. To view or change the option, choose Tools | Options from TestComplete’s main menu and the select the Engines | Recording category in the ensuing Options dialog. This will display the Recording settings on the right of the Options dialog.
To specify an asterisk as part of the window caption or class name, use double asterisks (for example, “MyWndCaption**”).
If the specified window does not exist, the Window() method posts an error message to the test log. Quite often, you need to check the window existance and do not post any error messages to the log. For instance, the creation of a window may take some time and you may need to pause the script until the desired window appears on screen. For this purpose, use the WaitWindow function. This function is similar to the WaitProcess function that we described above. It delays the execution until the specified window is created or the specified time period elapses:
[VBScript]
...
' Obtain the process called MyApp
Set p = Sys.Process("MyApp")
' Wait for a window for 3000 milliseconds
Set w = p.WaitWindow("MyWndClass", "MyWndCaption", -1, 3000)
' Check whether the window exists
If w.Exists Then
' The window exists
Else
' The window does not exist
End If
...

[JScript]
var p, w;

...
// Obtain the process called MyApp
p = Sys.Process("MyApp");
// Wait for a window for 3000 milliseconds
w = p.WaitWindow("MyWndClass", "MyWndCaption", -1, 3000);
// Check whether the window exists
if(w.Exists)
// The window exists
else
// The window does not exist
...

[DelphiScript]
var
p, w : OleVariant;
begin
...
// Obtain the process called MyApp
p := Sys.Process('MyApp');
// Wait for a window for 3000 milliseconds
w := p.WaitWindow('MyWndClass', 'MyWndCaption', -1, 3000);
// Check whether the window exists
if w.Exists then
// The window exists
else
// The window does not exist
...
end;

[c++Script, C#Script]
var p, w;
...
// Obtain the process called MyApp
p = Sys["Process"]("MyApp");
// Wait for a window for 3000 milliseconds
w = p["WaitWindow"]("MyWndClass", "MyWndCaption", -1, 3000);
// Check whether the window exists
if(w["Exists"])
// The window exists
else
// The window does not exist
...
Another way to pause the script until the desired window appears on screen is to use the process.Window() method and increase the value of the Auto-wait timeout project property. This property specifies the number of milliseconds TestComplete will wait when you address a process, window or control in scripts and this process, window or control is not available for some reaons. To change the property, right-click the project in the Project Explorer panel and select Edit | Properties from the context menu. TestComplete will open the project editor in the Workspace panel activate the editor’s Properties page. Choose the Playback category from the list that resides on the left of the page. The settings will be displayed to the right of the categories list.
For more information on pausing the script and waiting for windows and processes, see Waiting for a Process or Window Activation, Waiting for Object State Changes, Delaying the Script Execution and WaitChild in TestComplete help.
Note that we launched the Orders application as a non-Open application. We do this intentionally to demonstrate how TestComplete addresses windows of ordinary (non-Open) applications. However, if you launch the C# version of the Orders application without the NotOpenApp command-line argument, the application will become Open to TestComplete and to address forms, controls and objects, TestComplete will use names defined in the applications source code. For more information, see How TestComplete Recognizes Processes, Windows and Controls.
The next line in the script is --
[VBScript]
Call w1.MainMenu.Click("File|Open...")

[JScript]
w1.MainMenu.Click("File|Open...");

[DelphiScript]
w1.MainMenu.Click('File|Open...');

[C++Script, C#Script]
w1["MainMenu"]["Click"]("File|Open...");
It selects File | Open from Orders’ main menu. The name of the desired menu item is passed to the Click method of the MainMenu object. Item names in the item “path” are separated by vertical lines.
Note that you can address menu items by either their names, or by indexes. The menu item names can be used if the menu item has no picture and the application displays the item in the standard way (that is, if the style of menu items is not MFT_BITMAP or MFT_OWNERDRAW). Indexes let you work with menu items that cannot be addressed by their captions. Of course, item names make the script more readable, but indexes are more universal and work for almost all item types. If you are not sure how to address menu items, we recommend that you use indexes. See also Simulating User Actions in TestComplete help.
These lines come after a menu item is selected:
[VBScript]
Set w2 = p1.Window("#32770", "Open")
Call w2.Window("ComboBoxEx32").Window("ComboBox").Window("Edit").Keys("C:\Program Files\Automated QA\TestComplete 6\Samples\Open Apps\OrdersDemo\MyTable.tbl")
w2.Window("Button", "&Open").ClickButton

[JScript]
w2 = p1.Window("#32770", "Open");
w2.Window("ComboBoxEx32").Window("ComboBox").Window("Edit").Keys("C:\\Program Files\\Automated QA\\TestComplete 6\\Samples\\Open Apps\\OrdersDemo\\MyTable.tbl");
w2.Window("Button", "&Open").ClickButton();

[DelphiScript]
w2 := p1.Window('#32770', 'Open');
w2.Window('ComboBoxEx32').Window('ComboBox').Window('Edit').Keys('C:\Program Files\Automated QA\TestComplete 6\Samples\Open Apps\OrdersDemo\MyTable.tbl');
w2.Window('Button', '&Open').ClickButton;

[C++Script, C#Script]
w2 = p1["Window"]("#32770", "Open");
w2["Window"]("ComboBoxEx32")["Window"]("ComboBox")["Window"]("Edit")["Keys"]("C:\\Program Files\\Automated QA\\TestComplete 6\\Samples\\Open Apps\\OrdersDemo\\MyTable.tbl");
w2["Window"]("Button", "&Open")["ClickButton"]();
The first line returns the window object that corresponds to the standard Open File dialog. The second line simulates typing of the file name in the File Name field of the dialog. The simulation is performed by the Keys method. TestComplete automatically adds it to windows, which can accept keyboard input.
The next line in the script –
[VBScript]
w2.Window("Button", "&Open").ClickButton

[JScript]
w2.Window("Button", "&Open").ClickButton();

[DelphiScript]
w2.Window('Button', '&Open').ClickButton;

[C++Script, C#Script]
w2["Window"]("Button", "&Open")["ClickButton"]();
-- simulates pressing the Open button in the dialog. Pressing this button closes the Open File dialog.
Note: When recording a script, TestComplete uses the same process, window and control names that are displayed in the Object Browser panel. These names uniquely identify the object of the application under test, but can sometimes be too long and hard to understand. You can create a custom name for an object by using Name Mapping functionality and TestComplete will use this name during recording. By using the Name Mapping feature you will have clearer and more readable code. For more information on name mapping, creating custom names and using them when recording scripts, see Name Mapping, Adding Name Mapping Items and Name Mapping and Script Recording in TestComplete help.
The next instruction in the script returns us to Orders’ main window and simulates a mouse click on the Samuel Clemens node in the list:
[VBScript]
Call w1.Window("WindowsForms10.SysListView32.app3").ClickItem("Samuel Clemens", 0)

[JScript]
w1.Window("WindowsForms10.SysListView32.app3").ClickItem("Samuel Clemens", 0);

[DelphiScript]
w1.Window('WindowsForms10.SysListView32.app3').ClickItem('Samuel Clemens', 0);

[C++Script, C#Script]
w1["Window"]("WindowsForms10.SysListView32.app3")["ClickItem"]("Samuel Clemens", 0);
Note that we do not use any special command to activate the window where the script will “send” the click. TestComplete automatically activates the appropriate window.
Also note, that the window caption is not used to address the list view control on the main form of the Orders application (Window("WindowsForms10.SysListView32.app3")). The name is omitted because the form only contains one control with the class name WindowsForms10.SysListView32.app3.
The ClickItem method simulates a mouse click on the Samuel Clemens item in the list view. TestComplete automatically adds the ClickItem method to any window object that it recognizes as a list view control. To determine that a window is a list view window, TestComplete checks the window class name with the name given by default to windows of this type. If the check is successful, TestComplete treats the window as a list view control. Similarly, TestComplete determines the type of other windows. If the window class name differs from the default name, TestComplete uses Object Mapping settings to determine the window type. Once TestComplete determines the window type it adds methods and properties specific to windows of that type to the window object. All of TestComplete’s program objects for Windows controls have several methods to simulate mouse clicks within the controls. These methods let you simulate the click of an item displayed in the control or simulate mouse clicks using specified coordinates.
Now we have reached the instructions that were inserted into the script when we saved an image during recording:
[VBScript]
If (Not Regions.Compare(Sys.Process("Orders").Window("WindowsForms10.Window.8.app3", "*").Window("WindowsForms10.ToolbarWindow32.app3"), "Toolbar", False, False, True, 0)) Then
Call Log.Error("The regions are not identical.")
End If

[JScript]
if(!Regions.Compare(Sys.Process("Orders").Window("WindowsForms10.Window.8.app3", "*").Window("WindowsForms10.ToolbarWindow32.app3"), "Toolbar", false, false, true, 0))
Log.Error("The regions are not identical.");

[DelphiScript]
if not Regions.Compare(Sys.Process('Orders').Window('WindowsForms10.Window.8.app3', '*').Window('WindowsForms10.ToolbarWindow32.app3'), 'Toolbar', false, false, true, 0) then
Log.Error('The regions are not identical.');

[C++Script, C#Script]
if(!Regions["Compare"](Sys["Process"]("Orders")["Window"]("WindowsForms10.Window.8.app3", "*")["Window"]("WindowsForms10.ToolbarWindow32.app3"), "Toolbar", false, false, true, 0))
Log["Error"]("The regions are not identical.");
The Regions.Compare method is used to compare images. The method’s first parameter is the control on the screen and the second parameter specifies the picture which was saved to the Regions collection of the Stores project item as Toolbar. The other parameters allow you to exclude transparent pixels from comparison and take into account the mouse cursor image. For complete information on them, see method description in TestComplete help.
TestComplete provides similar comparison methods for files, object properties, databases, XML documents, web pages and other elements saved to the Stores project item. For more information, see About Checkpoints in TestComplete help.
You may wonder why you would need a comparison. The developers can change the toolbar and performing a comparison lets you check for this, before assuming your script is still pressing the right buttons. Due to the way the inserted code is written, you will get a log message if the comparison fails.
A more advanced solution would be to modify the script so that it is not dependant on button location: you can find the button image on the toolbar using the Regions.Find method and then simulate a mouse click in the found area. The only requirement is that you must first save the image of the button you are looking for to a file. For more information on this, see Comparing and Finding Images and description of the Regions.Find method in TestComplete help.
Note: It is recommended that you capture and save images using TestComplete, or capture images using the Windows shortcuts (ALT-PRTSCN or PRTSCN) and save them using MSPaint. Other screenshot applications may save the images with errors, which may cause incorrect results of image comparisons and finding operations.
The next script lines are --
[VBScript]
Call w1.Click(195, 10)
Call w1.Window("WindowsForms10.ToolbarWindow32.app3").ClickItem(5, False)

[JScript]
w1.Click(195, 10);
w1.Window("WindowsForms10.ToolbarWindow32.app3").ClickItem(5, false);

[DelphiScript]
w1.Click(195, 10);
w1.Window('WindowsForms10.ToolbarWindow32.app3').ClickItem(5, false);

[C++Script, C#Script]
w1["Click"](195, 10);
w1["Window"]("WindowsForms10.ToolbarWindow32.app3")["ClickItem"](5, false);
The first line simulates the mouse click over the title of the Orders application’s window. We did this click to activate the window since it had been inactive after we created the region checkpoint.
The second line simulates the selection of the Edit order button of the application’s toolbar. To perform this action, we use the ClickItem method. TestComplete automatically adds it to the objects, which it recognizes as toolbars. 5 is the button’s position on the toolbar (the ClickItem method can address the toolbar items by their captions, position or id. For more information, see the method description in TestComplete help).
The rest of the script code does not require any further explanation. It contains --
• Instructions that simulate user actions in the Edit order dialog.
• Instructions that simulate user actions when generating the customer list.
• Code used to close the application window and simulate user actions for the Save Changes request.
All methods and properties used here have been explained above.
Editing and Writing Scripts
General Notes
In many cases it is convenient to first record a script and then modify it in the Code Editor. However, sometimes it may make sense for you to create new scripts manually without recording anything. The Code Editor works well for this. It offers all modern editing features:
• Syntax highlighting
• Outlining
• Code templates
• Code navigation
• Text search and replace
• Clipboard capacities
• Etc.
The Code Editor has a Code Completion window with a list of objects and global functions which you can use in your scripts. See the Code Editor description in TestComplete help for a detailed overview of all Editor features. Of course, script code is text and you can edit it in any text editor.
For more information on writing script code in TestComplete, please see Scripting in TestComplete help.
Writing Comparison Code
The goal of our test is to compare whether the Orders application generates the customer list correctly. We recorded a script simulating user actions that export a list to a file. Now we have to write script code that compares the baseline copy of this file with the copy that will be generated by the script.
We will use the C:\CustomerList.txt file generated during the script recording as the baseline copy. Now we should add this file to our TestComplete project:
• Activate TestComplete’s Project Explorer panel.
• Right-click the Stores | Files node in the Project Explorer and select Add | New Item from the context menu. TestComplete will show the standard Open File dialog, where you can select the file to be added to the project.
• In the dialog select the file C:\CustomerList.txt and click Open. TestComplete will display the message box asking you whether it should copy the file to the Stores folder of your project. Answer Yes. TestComplete will copy the file to the Stores folder and then add the copy to the Files collection of the Stores project item. The added file will be displayed under the Stores | Files node in the Project Explorer:

• Open Windows Explorer or any other file manager and delete the C:\CustomerList.txt file. If you leave the file, then during the script run you will get a message box asking you whether to replace the existing file or not. This message box is an unexpected window for TestComplete since it did not exist during the script recording. TestComplete is able to handle unexpected windows appropriately (see Handling Unexpected Windows in TestComplete help). TestComplete will handle the message box by clicking its default button. However, it will post an error message about the window in the test log. So, the log will report that an error occurred during testing (despite the fact that this error was not significat and TestComplete was able to handle it). Deleting the file solves the problem with the error message.
Now we can write script code that will compare the files. You can write the comparison code manually, or generate the code using the Create File Checkpoint dialog. Let’s use the dialog:
• To call the dialog, select Create File Checkpoint from the Tools toolbar (if the toolbar is hidden, right-click within the toolbar area and choose Tools from the ensuing toolbars list):

TestComplete will display the dialog on screen:

• The files to be compared are specified in the File 1 and File 2 boxes of the dialog. Press the ellipsis button of the File 1 box and select the C:\CustomerList.txt file in the ensuing Open File dialog.
• To specify the other file for comparison, press the down arrow button of the File 2 box and choose CustomerList.txt from the drop-down list (the drop-down list displays the elements of the Stores | Files collection).

• Press OK. TestComplete will generate the file comparison code and display it in the Copy Text to Clipboard dialog. The generated code looks as follows:
[VBScript]
If (Not Files.Compare("C:\CustomerList.txt", "CustomerList.txt", 0, True)) Then
Call Log.Error("The files are not identical.")
End If

[JScript]
if(!Files.Compare("C:\\CustomerList.txt", "CustomerList.txt", 0, true))
Log.Error("The files are not identical.");

[DelphiScript]
if not Files.Compare('C:\CustomerList.txt', 'CustomerList.txt', 0, true) then
Log.Error('The files are not identical.');

[C++Script, C#Script]
if(!Files["Compare"]("C:\\CustomerList.txt", "CustomerList.txt", 0, true))
Log["Error"]("The files are not identical.");
As you can see, to compare the files, TestComplete uses the Files.Compare method with two parameters. One parameter specifies the file holding the exported data and the other specifies the file hodling the baseline copy of the data. Both parameters can point to files that reside on the hard drive, or to elements of the Files collection. For more information on comparing files, see File Checkpoints in TestComplete help.
• In our example, we will modify the generated code: we will place it within a routine and add the else statement. You can edit the code directly in the Copy Text to Clipboard dialog. The resultant version looks like –
[VBScript]
Sub CompareFiles
If (Not Files.Compare("C:\CustomerList.txt", "CustomerList.txt", 0, True)) Then
Call Log.Error("The files are not identical.")
Else
Call Log.Message("The files are identical.")
End If
Call Utilities.DeleteFile("C:\CustomerList.txt")
End Sub

[JScript]
function CompareFiles()
{
if(!Files.Compare("C:\\CustomerList.txt", "CustomerList.txt", 0, true))
Log.Error("The files are not identical.");
else
Log.Message("The files are identical.");
Utilities.DeleteFile("C:\\CustomerList.txt");
}

[DelphiScript]
procedure CompareFiles;
begin
if not Files.Compare('C:\CustomerList.txt', 'CustomerList.txt', 0, true) then
Log.Error('The files are not identical.')
else
Log.Message('The files are identical.');
Utilities.DeleteFile('C:\CustomerList.txt');
end;

[C++Script, C#Script]
function CompareFiles()
{
if(! Files["Compare"]("C:\\CustomerList.txt", "CustomerList.txt", 0, true))
Log["Error"]("The files are not identical.");
else
Log["Message"]("The files are identical.");
Utilities["DeleteFile"]("C:\\CustomerList.txt");
}
• Press Copy to copy the code to the clipboard and to close the dialog.
• Switch to the Code Editor and paste the copied code to your script unit.
• Select File | Save All from TestComplete’s main menu to save the changes.
In the next step we will include the CompareFiles routine into testing tasks and execute the test.
Specifying Execution Order for Tests
A test may include several subtests, each of which performs a smaller testing task. We say that test consists of test items. Each test item is associated with a script routine, low-level procedure, manual test, unit test or another project element that can be executed as a test.
You create the desired test items, specify their execution flow and modify properties on the Test Items page of the project editor. To open this page, right-click the project in the Project Explorer panel and choose Edit | Test Items from the context menu. TestComplete will open the project editor in the Workspace panel and activate the editor’s Test Items page. The page shows a tree-like structure of existing test items and lets you modify this structure as needed. The following image displays a sample Test Items page:

Test Items Page (Project Editor)
Note that the project suite editor also contains the Test Items page. It lets you specify the execution order of projects, which belong to this suite, by dragging the projects in the page:

Test Items Page (Project Suite Editor)
The difference between these pages is obvious: when you command TestComplete to execute a project, TestComplete will run tests defined with the Test Items page of the project editor. When you command TestComplete to execute a project suite, it will execute projects in the order specified on the Test Items page of the project suite editor.
By default, for each new project, TestComplete creates a new test item that launches the routine specified by the Main routine property of the Script’s project item. Let’s create new test items for script routines that we created on previous steps:
• Open the Test Items page by double-clicking the project node in the Project Explorer panel. TestComplete will show the project editor in the Workspace panel.
• Click Test Items at the bottom of the editor. TestComplete will open the Test Items edit page containing a tree-like structure of test items. By default, the page has only one test item that is associated with the main routine of the Script project item.

Let’s modify the properties of the existing test item so that it will be associated with the recorded script routine (Test1), but not with the main routine.
• To specify the test item’s source, press the ellipsis button of the Element to be run column. This will call the Select Test Item dialog.
• In the Select Test Item dialog choose Script | Unit1 | Test1 (the recorded script routine) and then click OK to save.

TestComplete will display the selected element in the Element to be run column.
Now let’s add a test item for the CompareFiles routine we created in the previous step:
• Right-click somewhere within the Test Item's edit page and choose New Item from the context menu. TestComplete will create a new empty test item.
• To specify the test item’s source, press the ellipsis button of the Element to be run column. This will call the Select Test Item dialog.
• In the Select Test Item dialog choose Script | Unit1 | CompareFiles and click OK. TestComplete will display the selected element in the Element to be run column.
Now the Test Items page contains two test items associated with script routines:

• Once you have created a new test item, you can modify its properties in a column of the Workspace panel. For instance, you can change the Count property to specify the number of times the test item will be executed, or modify the Timeout property to set the maximum time period for an item’s execution. If the test item’s execution time exceeds the specified timeout, TestComplete terminates the test item run and considers that the item failed to execute successfully. For more information on the properties that you can edit on the page, see Test Items Edit Page in TestComplete help.
To modify a property, click it twice (not double-click) on the page or select the property and press F2.
In our example, we will not modify the item’s properties.
Note: Make sure that the test item is enabled, that is, the checkbox on the left of the test item’s icon is selected. TestComplete executes a test item only if it is enabled.
We only created two test items. They will perform all of the steps described in the Creating Tests topic: they will launch the tested application, simulate user actions over it, save the list of customers to the file and compare it with a baseline copy. This is enough for our sample project. In real-life projects, you will typically need to create more than two test items. You can create as many test items as needed.
To change the position of a test item, drag it to the desired node in the Test Items page, or right-click the item and use the Move Up, Move Down, Indent and Outdent items of the context menu.
To remove a test item, select it in the Workspace and then choose Delete from the context menu.
Note: Test execution can be initiated from a script. That is, your project may contain only one test item that will refer to the Script’s main routine and all other script routines, low-level procedures, unit tests, manual tests, and so forth, can be called from this main routine. For information on how to do this, see Calling Project Elements From Scripts in TestComplete help.
Running the Created Tests
Before running tests, you should have completed the following preliminary steps:
• Define the test’s purpose.
• Create test items.
• Specify the test item’s execution order.
TestComplete can use different kinds of tests: scripts, low-level procedures, and so forth. Some of these tests can be recorded. Therefore, before running tests, make sure they start with the same initial conditions as the recording did. For instance, the script almost always requires the tested application to be running. So, before simulating the user actions, you should launch the application. To guarantee that the application is loaded, do one of the following:
• Right-click the application’s node in the Project Explorer panel and choose Run from the context menu (the tested applications are displayed as child items of the TestedApps item in the panel). To launch all tested applications, right-click the TestedApps item and choose Run All from the context menu.
Similarly, you can launch applications from the Tested Applications editor that is displayed in the Workspace panel.
-- or --
• Call the TestedApps.AppName.Run method at the beginning of the script. Our recorded script already contains this method call, since we started the Orders application from the Recording toolbar (when you do this, TestComplete automatically adds the method call to the recorded script):
[VBScript]
Sub Test1
Dim p1
Dim w1
Dim w2
Dim w3
Dim w4
TestedApps.Orders.Run
Set p1 = Sys.Process("Orders")
...

[JScript]
function Test1()
{
var p1;
var w1;
var w2;
var w3;
var w4;
TestedApps.Orders.Run();
p1 = Sys.Process("Orders");
...

[DelphiScript]
procedure Test1;
var p1 : OleVariant;
var w1 : OleVariant;
var w2 : OleVariant;
var w3 : OleVariant;
var w4 : OleVariant;
begin
TestedApps.Orders.Run();
p1 := Sys.Process('Orders');
...

[C++Script, C#Script]
function Test1()
{
var p1;
var w1;
var w2;
var w3;
var w4;
TestedApps["Orders"]["Run"]();
p1 = Sys["Process"]("Orders");
...
To launch all tested applications, you can call the TestedApps.RunAll method at the beginning of the testing script.
[VBScript]
Sub Test1
Dim p1
Dim w1
Dim w2
Dim w3
Dim w4
TestedApps.RunAll
Set p1 = Sys.Process("Orders")
...

[JScript]
function Test1()
{
var p1;
var w1;
var w2;
var w3;
var w4;
TestedApps.RunAll();
p1 = Sys.Process("Orders");
...

[DelphiScript]
procedure Test1;
var p1 : OleVariant;
var w1 : OleVariant;
var w2 : OleVariant;
var w3 : OleVariant;
var w4 : OleVariant;
begin
TestedApps.RunAll();
p1 := Sys.Process('Orders');
...

[C++Script, C#Script]
function Test1()
{
var p1;
var w1;
var w2;
var w3;
var w4;
TestedApps["RunAll"]();
p1 = Sys["Process"]("Orders");
...
Despite of the way you launch a tested application (via the menu item or with a method call), TestComplete will launch the application according to the run mode specified in the TestedApps editor.
If you launch an application under Windows Vista or Windows Server 2008 with administrator privileges, the operating system will display a dialog box asking for your permission for the run. Due to certain limitations, the closing of this dialog box cannot be automated (when this dialog box is visible, the script run is paused). You should either close the dialog manually, or modify User Account Control setttings so that Windows does not display the dialog. See Testing Applications With TestComplete Under Windows Vista and Windows Server 2008 in TestComplete help.
The created tests are not compiled into an executable for test runs. You run the tests directly from TestComplete. To run tests on computers that do not have TestComplete installed, you can use a resource-friendly utility called TestExecute. You can also export script code to an external application and run it there. For more information on this, see Connected and Self-Testing Applications in TestComplete help.
To run your test:
• Go to the Project Explorer panel (if this panel is hidden, select View | Project Explorer from TestComplete’s main menu).
• Click Run Project on the panel’s toolbar.
You can also start the project execution by pressing SHIFT-F3. This shortcut can be changed in the Global Shortcut Options dialog. To display this dialog, choose Tools | Options from the main menu of TestComplete and then select the General | Global Shortcuts in the ensuing Options dialog.
Not only can you execute projects, but any element that provides one or more tests: for example, a project suite, the Script project item, a low-level procedure, and so forth. To run the element, right-click it in the Project Explorer panel and select Run from the context menu. For instance:
• To “execute” the Script project item, right-click this project item and choose Run from the context menu. TestComplete will run the routine that is specified by the Main Routine property of the Script project item.
• To run an individual script routine, right-click the unit holding that routine and choose the desired script routine from the Run submenu of the context menu.
• To “execute” the project suite, right-click the project suite node and choose Run, or select Run Project Suite from the Project Explorer toolbar.
The test execution will last until the execution of all test items is over. You can stop the execution at any time by pressing Stop on the Test Engine toolbar or select Script | Stop from TestComplete’s main menu.
You can pause the test execution by clicking Pause on the Debug toolbar (if the toolbar is hidden, right-click somewhere within the toolbar area and choose Debug from the ensuing context menu). You can also pause the test execution by pressing the Pause script execution shortcut (you can modify this shortcut in the Global Shortcuts Dialog).
When paused you can perform any actions needed. For instance, you can close certain applications or explore the script variables and objects using TestComplete’s Watch List or Locals panel or the Evaluate dialog (see Debugging Scripts in TestComplete help). Also, if the Show Log on pause option is enabled, TestComplete displays the Pause Log window when you pause the test run. In this window you can review test results saved to the log when paused. The window is closed after you resume the test execution. To view or change the Show Log on pause option, choose Tools | Options from TestComplete’s main menu and choose the Engines | Log settings group on the left part of the ensuing Options dialog. TestComplete will display the log settings on the right of the Options dialog.
After the test execution is over, you can view test results using TestComplete’s test log. The next topic provides a brief overview of the log capabilities.
For complete information on running tests in TestComplete, on project settings that affect the runs and on the test execution peculiarities, see Running Tests in TestComplete help.
Analyzing Test Results
TestComplete keeps a complete log of all operations performed during testing. You can add your own notes, references or images to the log as well.
By default, TestComplete stores the results of each test run in subfolders of the \Log folder (you can specify another folder for the log files using the Log location project property). Each subfolder name includes the name of the executed test including the date and time of the run.
The titles of test results are shown in the Project Explorer panel under the Project_Suite_Name Log | Project_Name Log node, for example, ProjectSuite1 Log | Project1 Log. It is the primary workspace for looking up the test history of the project and project suite. Each node corresponds to a test run. An image to the left of the node specifies whether the corresponding test run passed successfully.
By default, projects store references to all log files. That is, the number of references kept by the project equals to the number of test runs. This number increases as the testing progresses, and, if the number of references is too large, you can remove the unnecessary logs by right-clicking them in the Project Explorer panel and selecting Delete from the context menu. To add existing log files to your project, right-click the Project Log node and selecting Add Log File from the context menu.
You can also limit the number of references kept by using the Number of recent logs to keep option. To view or change it, select Tools | Options from TestComplete’s main menu and on the left of the ensuing Options dialog, choose the Engines | Log group. TestComplete displays the log settings on the right of the dialog. The option specifies the number of log files stored in the project. If the option is enabled, newer log files will push out older log files from the list of stored results when the number of references exceeds the option value. TestComplete will delete both references to files and the files themselves, so if you want to store test results you should copy them. You can add the saved copy of the results to your project any time later as it is described above.
Note: TestComplete automatically adds nodes for the last results after the test execution is over. That is, the results are not displayed when the test is running. You have to wait until the test run is over.
However, you can view intermediate results if you pause the test execution. TestComplete includes a special Show Log on pause option. You can find it in the same Log Options dialog, in which the abovementioned Number of recent logs to keep option resides. If the Show Log on pause option is enabled, then during the pause, TestComplete displays the Pause Log window in the Workspace panel. The window is closed once you resume the test execution. The pause log is not added to the test log tree displayed in the Project Explorer.
To view the detailed test results, right-click the desired result in the Project Explorer panel and choose Open from the context menu. TestComplete will display the test results in the Workspace panel. In our example, the log is as follows --

The test results’ window shows results of one test run. On the left of the window there is a tree-like structure of the test that was executed during the test run. The tree reflects the hierarchy and flow of the executed tests and includes results of all executed test items: scripts, low-level procedures, unit tests and others. For instance, if you initiated load testing from a script, the Script log tree node will have a child node named Load testing log. If an event handling routine (script) was executed during the load testing run, the Load testing log node will hold another Script log node as a child.
In our case, we executed the project that has two test items with each one running a script routine. Let’s explore the test log nodes.
The root node of the tree corresponds to the start item of the test. In our case the root element corresponds to a project, since we ran the project. But if we ran a project suite, the root element would correspond to the project suite; if we ran the Script project item, the root element will be the Script log, and so on.
The root node has two child nodes. They correspond to test items that were executed by the project. Each of these test items executes one element - the script routine that is specified by the Element to be run column of the project editor’s Test Items page. The script logs are shown as child nodes of the test item nodes.
An image to the left of the node shows whether the test was successful and if errors or warnings occurred during its execution. TestComplete can generate error or warning messages to pinpoint application errors, as well as generate notifications for actions such as keypresses. Scripts can post any kind of message (see Posting Messages to the Log in TestComplete help). By expanding the nodes with error (or warning) icons, you can easily find which test operation failed to execute successfully.
To view detailed results for a node, simply select it from the log tree. TestComplete will display detailed results on the right. Note that every project item has its own results presentation, so what the log window displays is determined by what project item was used as a source of the test. For instance, the Script project item forms a log of records with informative, error, warning and picture messages (see the image above). The Remarks pane of the script test log contains additional information about the currently selected message. The Picture pane shows an image posted to the log. You can rearrange the log panels as it is described in the Arranging Columns, Lines and Panels topic in TestComplete help. For instance, you can resize the Remarks or Picture panes, sort the contents on the Time column, filter results by their type, and do a lot more.
To view a script line that post a message to the test log, double-click the desired message in the log. TestComplete will open the script unit and position the cursor at the appropriate script line.
The next topic of the Getting Started section, Searching for the Reason of an Error, describes how you can determine why your test failed to run successfully.
Searching for the Reason of an Error
It is possible that the first versions of your test scripts will fail to execute successfully. There can be a lot of reasons for this. For instance, the script code may contain a mistaken instruction, the application behavior can differ from what you expected or an unexpected window may appear during the script run. You can search for the cause of an error in the following way:
• Look at the first error in the test log (to view the script function that posted this error to the log, double-click the message in the log window).
• Run your script once again to analyze the application state when an error occurs. To perform this analysis you can --
 Set breakpoints or pause the test execution and use the Watch List or Locals panel and the Evaluate dialog to explore test objects and variables’ values (see Debugging Scripts in TestComplete help).
 Add script statements that will post different diagnostic messages to the log, for example:
- The list of child objects (windows).
- Images of one or several application windows.
- The state of objects (windows): existence, visibility, and so on. For instance, to see if an object or window exists, use the Exists property; to see if a window or an onscreen object is visible, you can use the Visible and VisibleOnScreen properties; to see if an object (window) is enabled or focused, use the Enabled and Focused properties.
The goal of the analysis is to answer the following questions:
• What is the difference between the current application state and the state you expect?
• What is the cause of the error: an error or typo in the script, an application bug or something else?
If you cannot determine the cause of an error, send a message to AutomatedQA’s support team at support@automatedqa.com (see Technical Support and Resources). In order for the support team to answer the message in a timely manner, please attach your script and archived results folder of your TestComplete project to the message (the project results folder is normally \Log directory). Please modify the script so that it gives detailed information on your application state at the moment of an error: images of application windows, the list of child objects of the tested process, and so on. A small sample application that illustrates the problem will be greatly appreciated.
You can also ask about the problem in our newsgroup or search for a solution in the list of frequently asked questions. For more information on this, see Technical Support and Resources.
Scripting
Writing Scripts – Overview
About Scripts
There are two basic ways to create a script:
• Record a script using TestComplete’s script recorder (see Recording a Test Script in TestComplete help).
-- or --
• Write a script in TestComplete’s Code Editor.
The easiest way to begin scripting is to use the recorder. The script can be edited further through the Code Editor.
A script is a procedure or function in one of the supported scripting languages (see the Scripting Languages section below). Scripts are grouped into unit files, and each project may use as many units as needed. In the hierarchy of project elements, all the units belong to the Script project item. When you create a new project, TestComplete automatically creates the Script project item with one unit in it.
A typical script that simulates user actions contains the following statements:
• Sys.Process(…) - This method returns an object that provides a scripting interface to the process of the tested application.
• processObj.Window(…), windowObj.Window(…) - These methods return windows of objects or child windows of a parent window (controls on an application form).
• windowObj.Click, windowObj.DblClick, etc., - These statements simulate user actions over a window.
For more information on these instructions, see How TestComplete Recognizes Processes, Windows and Controls and Simulating User Actions in TestComplete help.
Scripts may be called from other scripts, by name if in the same unit, else using the .