Locating Elements: attributes changed
Try our free SeleniumIDE replacement
Dynamically generated web pages are dynamic because something about them is expected to change. The more sophisticated the application, the more likely this becomes. As a result, certain parts of the page will be different each time the page is visited, or when it is visited by a different user or perhaps when the moon is in a different phase. When locating elements, care must be exercised to ensure that these changes do not prevent the locator from returning the correct element.
In this example, locating the username and password fields by the element ID or field name are likely to be an excellent strategy – they are unique and unlikely to change.
However, consider the next example, where we need to choose one of the serial# links to click. There are repeating rows, each with a similar link to click. If the link has an Element ID, it is likely to be related to the serial #- possibly the actual serial# or perhaps the id of the database row associated with the serial. Or it might be randomly generated by the one of the web application’s framework libraries. Either way, unless this page always contains the same list for every user that you will test visiting this page, the Element ID is unlikely to be a good choice. The same applies to the Field Name attribute, in the case of choosing an option from the Assigned To selector or clicking one of the submit buttons (e.g. Renew).
Choosing a better locator strategy depends on what the user should do.
Option 1: A particular user should always click on a particular serial#: Put that serial# in the dataset (along with the username and password) and use a Link Text locator with the dataset column as the source for the text. Below shows what the configuration of the locator might look like:
Note that clicking the edit button to the right of the locator field opens the data source dialog. There are many types of data sources, including datasets, which are tabular files that provide virtual users with values for data-driven tests (usernames, passwords, etc).
Option 2: The user should always click on the first (or second or third, etc) serial#: Use an XPath that locates the table and then traverses the DOM to the Nth row and the link in the first column. It might look something like this:
//*[@id="license_list"]/table/tbody/tr[2]/td[1]/a/span
This locates the section of the page that contains the table of licenses and then navigates down the DOM to the desired link. The ‘2’ in ‘tr[2]’ indicates elements in the 1st row of the table (in an HTML DOM, the headings are typically implemented as row #1).
XPath and structural changes
Developers frequently make changes to the internal structure of the page that are not visible when rendered on the screen. But some XPath expressions can be highly sensitive to the structure and become broken due to changes. In the example above, if the developer wrapped the target link inside another tag (e.g. <em>, <u>, etc), it would break the XPath locator. While this will not typically happen during a test, it may happen frequently enough during a long testing cycle to make it worthwhile to write the XPath expression differently or even choose a different type of locator.