Chain Optimization

When recording or creating tests via the explorer with a complex application you will wind up with some giant chains and it’s important to have a thorough understanding of how chains work so you can minify those chains down into their most concise form.

First it’s important to understand that each piece of a chain /location:value/ is a viable stand alone chain that gets you to a piece of the UI. Knowing that it makes it easier to see that large chunks of the chain is probably not necessary.

Another important thing to know is that any piece of the chain that is the type of the UI component concatenated with a string is probably dynamic and therefore undesirable parts of the chain as they negatively affect reliability.

• Note: You may be able to record a test with dynamic pieces and play it back over and over again over multiple builds, but when you try the same test on a different platform (linux for example) the VM is different and therefore will probably generate slightly different dynamic names (thus breaking your test).

A great example is the following:

chain=name:PortBooks0/id:mainView/id:sliderPanel/id:bookHolder/id:bookPnl/id:cover/name:canvasRender3398/name:framedPhoto3407/name:TextArea3405/name:UITextField4232

The first thing to do is identify the first reliable ID link in the chain, in this case it’s /id:cover/, we can start here and remove all of the preceding links in the chains, giving us the following:

chain=id:cover/name:canvasRender3398/name:framedPhoto3407/name:TextArea3405/name:UITextField4232

At this point you will start in with some trial and error, there is an available wildcard feature that can be used to try and deal with some of the dynamic links, I would try it one step at a time starting on the left making sure the chain still operates properly.

chain=id:cover/name:canvasRender*/name:framedPhoto*/name:TextArea*/name:UITextField*

The problem with this approach is that if you have multiple children that all match the wildcard and are the final link in the chain, the first match will be used — which is why we are working on a syntax to specify children as part of the chain.

Shortening for ID’s

If you find yourself in a situation where you have a super long chain where the last link is an id, like the following /id:myTextBox, you can simply remove everything except for that last link in the chain.

chain=id:cover/name:canvasRender3398/name:framedPhoto3407/name:TextArea3405/id:myTextBox

Becomes:

chain=id:myTextBox

Another recently available solution is the ability to specify the child you would like to use, so from the above chain:

chain=id:cover/name:canvasRender3398/name:framedPhoto3407/name:TextArea3405

If the node we actually want is the 3rd child of /name:framedPhoto340/, we could simply say:

chain=id:cover/name:canvasRender3398/name:framedPhoto3407/child:[2]

(keep in mind that the counting of an array starts at 0.)

Currently in Development

• Explorer and recorder generation of child locators as a fallback

Clearly the best solution is to give as much of the tree automationName properties, or ID’s, but when that can’t happen these are the venues that you can take to create robust tests.