The process of creating a custom component that supports automated testing is called instrumentation. Flex framework components are instrumented by attaching a delegate class to each component at run time. The delegate class defines the methods and properties required to perform instrumentation.

If you extend an existing component that is instrumented, such as a Button control, you inherit its parent's instrumentation, and are not required to do anything else to make that component testable. If you create a component that inherits from UIComponent, you must instrument that class in one of the following ways:

• Create a delegate class that implements the required interfaces.
• Add testing-related code to the component.

You usually instrument components by creating delegate classes. You can also instrument components by adding automation code inside the components, but this is not a recommended practice. It creates tighter coupling between automated testing code and component code, and it forces the automated testing code to be included in a production SWF file.

In both methods of instrumenting a component, you must specify any new events to the agent. For QTP, you must add your new component's information to a class definitions XML file so that QTP recognizes that component. For more information about this file, see Using the class definitions file.

Consider the following additional factors when you instrument custom components:

• Composition. When instrumenting components, you must consider whether the component is a simple component or a composite component. Composite components are components made up of several other components. For example, a TitleWindow that contains form elements is a composite component.
• Container hierarchy. You should understand how containers are viewed in the automation hierarchy so that the QC professional can easily test the components. Also, you should be aware that you can manipulate the hierarchy to better suit your application by setting some automation-related properties.
• Automation names. Custom components sometimes have ambiguous or unclear default automation names. The ambiguous name makes it more difficult in automation tools to determine what component a script is referring to. Component authors can manually set the value of the automationName property for all components except item renderers. For item renderers, use the automationValue.