Containers are different from other kinds of controls because they are used both to record user interactions (such as when a user moves to the next pane in an Accordion container) and to provide unique locations for controls in the testing scripts.

Adding and removing containers from the automation hierarchy

In general, the automated testing feature reduces the amount of detail about nested containers in its scripts. It removes containers that have no impact on the results of the test or on the identification of the controls from the script. This applies to containers that are used exclusively for layout, such as the HBox, VBox and Canvas containers, except when they are being used in multiple-view navigator containers such as the ViewStack, TabNavigator or Accordion containers. In these cases, they are added to the automation hierarchy to provide navigation.

Many composite components use containers, such as Canvas or VBox, to organize their children. These containers do not have any visible impact on the application. So, you usually exclude these containers from being tested because there is no user interaction and no visual need for their operations to be recordable. By excluding a container from being tested, it does not clutter the test scripts and make them harder to read.

To exclude a container from being recorded (but not exclude its children), set the container's showInAutomationHierarchy property to false. This property is defined by the UIComponent class, so all containers that subclass UIComponent have this property. Children of containers that are not visible in the hierarchy appear as children of the next highest visible parent.

The default value of the showInAutomationHierarchy property depends on the type of container. For containers such as Panel, Accordion, Application, DividedBox, and Form, the default value is true; for other containers, such as Canvas, HBox, VBox, and FormItem, the default value is false.

The following example forces the VBox containers to be included in the test script's hierarchy:

<?xml version="1.0"?>
<!-- at/NestedButton.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:Panel title="ComboBox Control Example">
        <mx:HBox id="hb">
            <mx:VBox id="vb1" showInAutomationHierarchy="true">
                <mx:Canvas id="c1">
                    <mx:Button id="b1" 
                        automationName="Nested Button 1" 
                        label="Click Me"
                    />
                </mx:Canvas>
            </mx:VBox>         
            <mx:VBox id="vb2" showInAutomationHierarchy="true">
                <mx:Canvas id="c2">
                    <mx:Button id="b2" 
                        automationName="Nested Button 2" 
                        label="Click Me 2"
                    />
                </mx:Canvas>
            </mx:VBox>         
        </mx:HBox>
    </mx:Panel>    
</mx:Application> 

Working with multiview containers

You should avoid using the same label on multiple tabs in multiview containers, such as TabNavigator and Accordion containers. Although it is possible to use the same labels, this is generally not an acceptable UI design practice and can cause problems with control identification in your testing environment. QTP, for example, uses the label properties to identify those views to testers. When two labels are the same, QTP uses different strategies to uniquely identify the tabs, which can result in a confusing name list.

Also, dynamically adding children to multiview containers can cause delays that might confuse the testing tool. You should try to avoid this.