Flash Player has reached end of life on December 31, 2020. Support for Flash and Flex applications is now deprecated in TestComplete and will be removed in a future release.

The information in this topic applies to web tests that locate web objects by using internal identification properties provided by TestComplete and run in local environments.

In order for TestComplete to get access to the internals of a Flash or Flex application, the application must be prepared in a special way before testing. For detailed instructions, see Requirements for Testing Flash and Flex Applications.

Besides the compulsory preparation operations that make your Flash or Flex application testable, you can also make use of some techniques that make the application more test-friendly and allow you to achieve better results. Below are some recommendations on preparing source code of Flash and Flex applications for testing with TestComplete.

Specify meaningful names for tested application objects. If you access the tested application’s internals by using the debug version of Flash Player or running the application within the Runtime Loader or if the application was compiled with the FlexClient helper library, tested Flash objects are addressed in tests by object type names and native names or by object labels specified in the application’s source code.For instance:

Button("EditOrder")

RadioButton("SecureConnection")

TextInput("FirstName")

Make sure that all the objects to be tested have names specified in the source code before compiling it. Also, use meaningful strings for names of Flex objects to make references to these objects in tests more human-readable. For instance, the SubmitButton name is preferable to Button1 when naming a button that initiates submitting some data entered in the application form. Such meaningful object names make object addressing in your tests more intelligible.

TestComplete uses the following principles to name objects within your Flash and Flex applications:
- TestComplete tries to address Flash and Flex objects by the value specified in the native id property. That is, you can specify a meaningful identifier in this object property in your application’s source code.
- If TestComplete does not find any value in the id property, the object is addressed in tests by the native name property. TestComplete will use the value specified in this object property to identify the appropriate object in tests.
- If the name of a Flash or Flex object is not specified in the application (or if it is generated automatically), TestComplete tries to address such an object by its label (if any). So, you should also specify a meaningful label in the native label property of the object in your application’s source code.
- If TestComplete does not find any value in the label, name and id object properties, the object is addressed in tests by the object type name and index among other objects of the same type that are located on the same hierarchy level (for instance, CheckBox(0)). Tests with such references to tested objects are less readable, that is why you should specify meaningful names for all tested objects in your Flex code.
If you use the Microsoft Active Accessibility (MSAA) technology to get access to the tested Flash and Flex applications’ internals, TestComplete identifies Flash and Flex objects in tests by object type names and accessibility names specified in the application’s source code. In this case, you should specify meaningful captions for controls in your Flash or Flex application where it is possible, so that TestComplete can use these captions for referring to objects in tests.
Avoid renaming objects at run time. Since Flash and Flex objects are addressed in TestComplete tests by native names, identifiers or captions specified in the application’s source code, you should not change the values of the name, id and label object properties in your tested application at run time to avoid problems with object recognition.

Tips on Creating Testable Flash and Flex Applications

See Also