Justification:
Testing Static Content is the first and foremost test procedure to check the existence of a static, non-changing, UI element in any Selenium test automation. This mechanism used in test automation for improving the maintenance and extensibily of your automation suite. This is taken into account as a Selenium Test Design Considerations which is mentioned in the official SeleniumHQ website.

http://seleniumhq.org/docs/06_test_design_considerations.html

Choosing a Location Strategy:

There are multiple ways of selecting an UI object on a page. But what is the trade offs of each of these locator types? We can locate an object using mechanisms mentioned below:
• the element’s ID
• the element’s NAME attribute
• an XPath statement
• by a links text
• document object model (DOM)
Using an element ID or name locator is the most efficient in terms of test performance, and also makes your test code more reliable; if the ID or name within the page source is well-named.

Selenium supports several locators, of which XPaths are the most expressive of them all.

XPath statements take longer time to process since the browser must run its XPath processor.

Xpath has been known to be especially very slow and some time it’s may not work in Internet Explorer version 7. Which in turn cause Element not found Exception and fails many of our test cases due to this reason.

Xpath are very slow in IE especially in multi-window mode (which is Selenium’s default mode).
To use Selenium in single-window mode, just start selenium with the -singleWindow flag. But In single window mode, the difference was lesser at IE 8 being somewhere around 2-3 times slower. Single-window didn’t work for several situations in the application. For instance we would loose the session in the popup window in some situations or the JavaScript on the page interfered with Selenium’s js and a few other problems. For this reason we couldn’t use it.
As described in the document focused on Selenium locators, there are other alternatives to XPaths that are faster. If we can use id and name attributes, that would be a great option.
CSS and DOM would work for a larger set of cases; however, it can’t be used for all the elements either. Going back to our situation, several elements we needed to target happened to have ids but they were dynamically generated and so we couldn’t use it with Selenium’s out-of-the box capabilities.

Cheers,
Manu V Gorur

Now, why didn’t I think of that?

Sorry, mate. I’ll probably have some more questions after I try making a map file for our app (lots of jQuery and whatever custom controls our team grabs each day…).

Cheers,
bcw