TestComplete samples (both built-in and additional) are located in the <Users>\Public\Public Documents\TestComplete 14 Samples folder.
Some file managers display the Public Documents folder as Documents.
This topic provides a brief overview of testing unmanaged Visual C++ applications with TestComplete.
With TestComplete you can easily test Visual C++ applications. You can perform any kind of testing – unit, functional, regression and so on. The easiest way to create a test for your application is to record a keyword test or script routine. When playing back a test, TestComplete repeats all the recorded actions you performed over the tested Visual C++ application during recording. If needed, you can also extend the recorded test manually using a number of specific features provided by TestComplete.
TestComplete can get access to internal objects, methods and fields of unmanaged Visual C++ applications that were created using the MFC, ATL, WTL or wxWidgets library and with one of the following compilers:
Visual C++ v. 7.x - 16.0 (Visual Studio 2005 - 2019, unmanaged classes)
Intel C++ 11.0
If you work with Microsoft Visual Studio 2005 (v. 8.0) you should install Service Pack 1 for it.
For information on how to test Visual C++ .NET applications, see the topics of the Testing .NET Applications section.
There are two possible approaches to expose internal members of a Visual C++ application with TestComplete. You can expose the internals of the Visual C++ application under test by using wrapper classes supplied in a special DLL or by using the application’s external debug information.
In order for TestComplete to be able to use wrapper classes, the tested Visual C++ application should be built with compiler settings that enable generation of runtime type information (RTTI). For detailed information on how to enable these settings, see the topics of the Preparing Visual C++ Applications for Testing section.
Wrapper classes are defined for:
CObject and its descendants (except for template classes),
Win32 structures that are used as parameters of class methods,
MFC classes which are not inherited from
CObject (for example,
CRect, etc.) and for MFC structures that are used as parameters of class methods.
User-defined class members have no predefined wrappers, that is you can work only with members of these classes that are inherited from standard MFC classes (for example, if your class is inherited from
CWnd, your tests will be able to work with members inherited from
Wrappers allow you to access the public properties and methods of Microsoft Foundation Classes (MFC) from your tests. Public data members exposed by wrappers are displayed on the Properties page of the Object Browser panel. Note that TestComplete changes the names of class members by adding their class names as prefixes. That is, for example, to call the
GetHandle method of the
CWnd object from your test, you must use the
CWnd_GetHandle name. For detailed information, see Changes in MFC Classes Notation.
Another approach to getting access to your application’s internals is to compile your tested application with external debug information. For detailed information on how to do this, see Preparing Visual C++ Applications for Testing.
Once your Visual C++ application is compiled with debug information, the TestComplete Debug Info Agent™ enables you to access public, protected and private members of MFC, ATL, WTL and wxWidgets tested applications. The internal data members exposed by Debug Info Agent™ are displayed on the Fields page of the Object Browser.
Note that you can still test your application compiled with debug information using the properties and methods exposed by wrappers. However, you should keep in mind that it takes time for the Agent to read debug information. That is, if you do not use methods and fields exposed by Debug Info Agent™ in your tests, you should disable Debug Info Agent™, or compile your application without debug information.
You may also compile your Visual C++ application with dynamically linked MFC or wxWidgets libraries. When MFC or wxWidgets is linked dynamically, the DLLs are not built into the application and TestComplete uses wrapper classes rather than Debug Info Agent™. However, if MFC or wxWidgets elements are exposed by wrappers, you do not have access to protected and private class members.
With TestComplete, you can record and play back user actions in Visual C++ applications, or you can create tests manually from scratch. Usually, it is easier to record the test first and then modify and enhance the recorded test.
When you record a test, you interact with the tested Visual C++ application as an end-user would: navigate through the application’s screens, fill out forms and so on. TestComplete captures all actions you perform in the application and adds them to the test.
A test consists of a sequence of operations that define various interactions with objects in the tested application. For example, in the sample test below you can see that item selection from a combo box is represented by the
ClickItem operation, text input into text boxes - by the
SetText operation, and so on.
dlgNewOrder = Aliases.Orders.dlgNewOrder;
edit = dlgNewOrder.Edit;
def Test1(): dlgNewOrder = Aliases.Orders.dlgNewOrder; comboBox = dlgNewOrder.ComboBox; comboBox.ClickItem("FamilyAlbum"); edit = dlgNewOrder.Edit; edit.Click(7,13); edit.SetText("John Doe"); dlgNewOrder.btnOK.ClickButton();
Set dlgNewOrder = Aliases.Orders.dlgNewOrder
Set edit = dlgNewOrder.Edit
Call edit.SetText("John Doe")
var dlgNewOrder : OleVariant;
var comboBox : OleVariant;
var edit : OleVariant;
dlgNewOrder := Aliases.Orders.dlgNewOrder;
comboBox := dlgNewOrder.ComboBox;
edit := dlgNewOrder.Edit;
dlgNewOrder = Aliases["Orders"]["dlgNewOrder"];
edit = dlgNewOrder["Edit"];
The recorded tests can be modified and enhanced in a number of ways to create more flexible and efficient tests. For example, you can:
Add new operations, reorder operations and modify their parameters.
Delete or disable unneeded operations (for example, superfluous recorded operations).
Insert checkpoints for verifying objects and values in the tested application.
Create data-driven tests that run multiple test iterations using different sets of data.
Refer to the following topics to learn more about creating and enhancing tests:
|Creating tests using recording||Recording Tests|
|Creating tests manually||Keyword Testing and Scripting|
|Simulating user actions||Working With Application Objects and Controls|
|Running tests||Running Tests|
|Launching applications automatically at the beginning of the test run||Adding Tested Applications and
Running Tested Applications
|Creating checkpoints for verifying application behavior and state||Checkpoints|
|Running multiple test iterations using data from an external file||Data-Driven Testing|
There are two major test formats in TestComplete:
Keyword tests - visually configured tests with grid-based editing interface. Best suited for novice users and those without programming knowledge.
Scripts - code written in one of the supported scripting languages. May be better suited for advanced users.
You select the test type when creating a test and cannot change it later. However, you can mix keyword tests and scripts within the same test project and call them from each other.
TestComplete also includes additional test types, such as low-level procedures, unit tests, distributed tests and so on. You can use them to address specific testing needs. However, most automation is typically done using keyword tests and scripts.
Each object in an application has a number of properties, such as its location, text, type and so on. Some object properties are persistent and unchanging, and therefore can be used to locate objects in applications and differentiate among various objects.
When you record a test, TestComplete captures all windows and controls that you interacted with during the recording session and adds them to the Name Mapping project item (also known as the object repository or GUI map). For each captured object, TestComplete does the following:
Selects a set of properties and values that uniquely identify the object in the application and saves them to Name Mapping as the object identification criteria. These properties will be used for locating the object during subsequent test recording, editing and run sessions.
Generates an alias (name) that will be used to reference this object in tests. By default, TestComplete generates aliases based on object names defined in the application by developers.
Automatically captures and adds images of the mapped objects to the Name Mapping repository. This helps you understand which window or control one or another mapped object matches.
The following image shows sample Name Mapping for a Visual C++ application:
Here, the SysListView32 object is identified only by one property -
WndClass. This property specifies the window class name as it is defined by the application developers in the application’s source code. However, Visual C++ application objects can also be located by other properties, such as their class name, text and so on -- whatever best identifies a specific object.
If needed, you can modify the default Name Mapping generated by TestComplete. For example, you can:
Change the identification properties and values to define more robust identification criteria or to reflect major GUI changes in newer versions of the tested application.
Rename aliases to more meaningful and descriptive aliases, so that it is easier for you to understand which object is which.
Manually add new objects to Name Mapping.
For more information, see Name Mapping.
Keep in mind that the object hierarchy in Name Mapping mirrors the object hierarchy in the tested application. When locating an object, TestComplete takes into account its entire parent hierarchy. If any object in the parent hierarchy cannot be found using the specified property values, the target object cannot be located as well. That is why it is important to select unique and unchanging properties for object identification.
TestComplete recognizes individual controls of Visual C++ applications and lets you interact with them both at design time and during test recording or playback. In addition, it simplifies testing of the application's user interface since it includes special features used to test most frequently used Visual C++ controls.
For detailed information on support for Visual C++ application controls, see Support for Visual C++ Applications' Controls.
If the tested Visual C++ application is built with runtime type information, TestComplete enables you to access the public properties and methods of Microsoft Foundation Classes.
If the tested application is compiled with external debug information, TestComplete provides you with access to the application’s public, protected and private methods and fields. For detailed information on how to compile Visual C++ applications with debug information, see Preparing Visual C++ Applications for Testing.
|Note:||Note that some native properties, fileds and methods of Visual C++ objects are unavailable to TestComplete. For more information, see Object Properties, Fields and Methods That Are Unavailable to TestComplete.|
For detailed information on how to address exposed properties and methods from your tests, see Accessing Native Properties and Methods of Visual C++ Objects and Addressing Objects in Visual C++ Applications.
To see what operations (methods) are available for objects in your tested Visual C++ application, as well as the object properties and their values, you can use the Object Browser or Object Spy. The available properties and methods include those provided by TestComplete, as well as native object properties and methods defined by the developers in the application’s source code.
You can view the object properties and methods both at design time and at run time when the test is paused.
TestComplete includes a sample test project that demonstrates how to test Visual C++ applications:
|Note:||If you do not have the sample, download the TestComplete Samples installation package from the support.smartbear.com/downloads/testcomplete/samples/ page of our website and run it.|
For further information about automating tests with TestComplete, refer to the following sections: