When interviewing candidates for UI automation openings, I like to give them typical automation ‘problems’ to solve. Most of the problems provide them with a picture of a UI and the corresponding HTML, and ask how they would automate something given a tricky DOM. I’m finding that many of the candidates have experience in writing automation scripts, but are still stomped by these interview questions. Many of them respond with “I’d need Firebug to answer that”.
Please don’t be so dependent on Firebug, or any other browser’s dev tool. They are great to show you the DOM, but you should not rely on them to accurately give you proper handles to elements. Especially not in this day of modern web development where applications are being created with fancy Javascript libraries that pretty much guarantee a dynamic DOM.
Blindly depending on Firebug’s xpath or css selector recommendations is a sure-fire path to unstable scripts. I honestly can’t think of the last time I coded a scenario and was able to rely on the static identifiers for 100% of the elements involved in the scenario. There’s always one or two that require a bit more thought on how to reliably get a handle to it in different situations. As an automation engineer, it makes maintenance a lot more manageable if you develop your scripts with a good understanding of the DOM (including the relationships between nodes), and how to craft reliable xpath and css selectors.
Are you ready to fire Firebug? Or at the very least, be able to question the information it provides you? If so, here are some resources I’d recommend to help you be more efficient at identifying elements:
Understanding the DOM
Xpath Statements
- How to Write Smart XPath Locators
- Xpath in Selenium
- XPath in Selenium WebDriver
- The 10-Minute Xpath Tutorial
- Xpath Syntax
CSS Selectors
Locators for UI Automation
Nice post. FireBug is handy for when you are getting started, but when you work with anything but the most basic of applications, the CSS / XPath that it throws out is often wildly inefficient or simply unusable (particularly if the page has dynamic content loaded through JS, for example)
I had a lot of fun writing an automation library that would find the form control on the browser based on its label. For buttons, it’s easy to find, but for fields in tables, it was trickier, but doable, particularly if it’s meant for only one organization (but a lot of it is generalizable).
It is a great post Angie! You wrote the realities of locator selection strategies in real life. I want to thank you for referring my article on XPath. Also, I have written articles on CSS locators and successor of firepath (Selocity).
CSS: http://www.swtestacademy.com/css-locators/
Selocity: http://www.swtestacademy.com/ranorex-selocity/
Just to be smart-alecky… I would say the developers need to improve the “Testability” of the page and objects by using unique identifiers for the Name and/or ID values for the objects on the page. But even then with some object classes like tables and accordion that can be re-used multiple times on a page you need to do more digging in the DOM and put in the supporting code to handle them. It just seems developers today are too quick to use Star Wars programming style (D2P2, drag-drop-plug and pray) with the toolkits.
1. Agreed that one should not rely on firebug to get the css or xpaths locator of Web element and should have good knowledge of DOM, css and xpaths.
But
Firepath is really excellent to testify custom locators and I am really sad that Firefox is no more supporting firebug.
Coming from a project where all pages were build as atoms / panels and IDs where dynamically generated, I heavily crelied on firebug and firepath combo. To simply “fire” Firebug I think is too much of a hasty decision. I believe it is a time saver. I like it cause it helps me identify quickly the elements, however, and this is a big however… I never rely on the xpath provided. They tend to be too “hard-coded” and therefore make the element identification very brittle. Yes you need to master the skill of traversing xpaths using the wildcards provided by the specification. Same for CSS Selectors. So I would say do not fire yet Firebug, but accept its limitations and use best practices for your XPATHS.
Just used this as a refresher on XPATHS, thanks Angie!