GUI mapping strategy in test automation

Answer 1

If the element has an id that is used by scripting/css, we use that ID in testing. Otherwise we actively instrument our HTML for testing. By this I mean we can add an id just for testing to avoid any ambiguity. We usually give it a prefix to indicate this, ie. id="ftGoogleButton". This is so the people who work with the HTML only will understand that there is automated testing associated with the element. This convention is practical because they will normally only look in css/js for references to a given id.

Answer 2

I'd do the same, pick the first formulation rather than the second... for most tests.

You want your tests to break upon changes that are relevant to the functionality covered by those tests, and you want the same tests to ignore most other changes to the app.

So, if you're checking that a search for "foo" should return more than zero documents, that has nothing to do with the structure of the page and should ignore such changes.

However, in a test written to ensure that a search form is equipped with a submit button, you'd want to embody those assumptions in the XPath used to navigate from the form to the button.

Answer 3

As krosenvold said, getting developers to standardise on html name and/or id attributes and using those is one of the best strategies. My paper Test Automation as a Development Requirement discusses this topic and other things that developers can do to make applications more automation-friendly.

You should also ensure that all your object identification properties are stored in one central repository to make any subsequent maintenance easier. Most commercial tools have this feature built-in but with an open source tool you might need to roll your own mechanism.