Web Element Locator Strategies [A Student's Experience]
We talk about web element locators and their utility in web application testing strategies.
Join the DZone community and get the full member experience.Join For Free
I wanted to know about web element locators. In my free time, I am taking courses on Test Automation University, sponsored by Applitools. We are getting some of the best minds in test automation to present their approaches to testing web software. You may have read my review of Amber Race's course on API testing.
I took Andrew Knight's course on Web Element Locator Strategies to learn about how locators play a huge role in test automation — or just testing in general. Andrew is also a star teacher, consultant, and practitioner in the areas of software development and testing. You can read his blog at https://www.automationpanda.com/
Author's note: I now get why all his duckduckgo.com searches are for "Giant Panda." Duh.
Web Element Locators: Controls for Software Testing
Back when I started out in technology, I worked for a company that made test equipment for computer chips. For chips, the interfaces are pins, and while you try to exercise the chip for functional test, you did so through the pins. To measure behavior, you did so through the pins. The pins were the locators for the device under test.
With web software, the inputs and outputs can be identified by web element locators. If you are an experienced tester, you're probably thinking, "Gee, Michael, we knew that!" In fact, if you're an experienced tester, you probably have lots of experience dealing with locators. But, this course isn't for you; it meets the needs of people learning about web element locators.
So, I assume I scared off the experienced people, leaving you — a reader who wants to learn about this approach to testing.
Web element locators provide software identifiers you can use to select and monitor elements of the code that you want to test. I am being specific and deliberate with this description, as the terms matter. Locators are software reference points that allow you to pull data from and push data to a web page and measure its response. It's important to have good locators.
Web Element Locators Change, Don't They?
Unlike device pins, locators as identifiers might change from build to build — depending on coder practice. Identifiers might be identified in HTML code by ID or Name and can be recognized directly. Others might be identifiable by Class name. At times, the only identifiers are CSS, XPATH, or text on the page. You may have to be creative.
On a given web page, any object can be identified explicitly through the domain object model (DOM) relative to the root <html> of the page. Andrew made this clear — it's impractical to use the explicit call relative to the DOM for two reasons: complexity and fragility. The DOM can be nested many layers deep, and a call through multiple layers every time is both unreadable and unnecessary. And, using the DOM location will fail when the code changes.
Sometimes developers use the same identifiers for different elements in a table or other programmatic output. In such cases, the identifiers can be indexed (so long as they are used consistently) so that test code can be the "Nth" instance of a given identifier.
Valuing Consistency in Identifiers
Andrew made it clear that locators are code-generated. Sometimes, coders define an application with consistent IDs or names for objects that don't vary from release to release. These identifiers are excellent for building test automation. Everything else that depends on CSS or XPath — or even named fields — can vary when a coder updates an app.
Andrew didn't say, but I inferred from his course, that there is a separate Design for Testability skill set that developers must possess to make any test automation work across releases. In other words, when developers add IDs, names, or Class names, they should ensure that such names are used uniquely and/or consistently from release to release on functions that behave identically between those releases. Since testing depends on those identifiers, any change will cause tests to fail.
A large part of the course goes through specific kinds of identifiers and their relationships. For instance, I can look for exact matches of identifiers. The most obvious kind is "id=" attributes, which, according to HTML standards, must be unique on a given page. The "name=" attributes are added by programmers for input-related elements.
Added Benefit: Learning Developer Tools
The course uses Developer Tools in Chrome to help show how different identifiers are used to identify specific elements in the DOM. There is a comparable package on Firefox. I had never used Developer Tools before, and I found them to be quite useful and interesting. You can launch Developer Tools from the Chrome menu (View > Developer > Developer Tools). You can use a keyboard shortcut. On my Mac I launch Developer Tools by pressing CMD-Option-I at the same time. And, lastly, you can use the three dots at the top far right of the Chrome Screen to display the internal menu and pull down to (More Tools > Developer Tools).
My big tip for you is to know that there is a Find function in Chrome Developer Tools. You can display the Find box in Developer Tools, but only by hitting CMD-F (ctrl-F on Windows or Linux) while the Developer Tools is in focus. So, to generate the Find box, click somewhere in Developer Tools. Otherwise, you'll open up the find box for the screen you're inspecting. I spent a large amount of extra time learning to use the Developer Tools package in Chrome.
Once you launch Developer tools, you can click anywhere in the text and see what gets highlighted on the web page. Similarly, there is a selection tool (looks like an arrow cursor in a box at the top left of the Developer Tools screen). You can select anywhere on the page and highlight the corresponding text in the HTML. All in all, it's a great toolset to learn. We only touch on Developer Tools can do in the course.
Practical Examples of Identifiers
The course goes through examples for the https://www.duckduckgo.com/ search engine.
On a page with search results, the box for entering a new search has the id attribute:
which is unique on the page. However, the name attribute for the same box is
That could be simpler. It could also be more fraught between builds — depending on how the box got the name "q" in the first place.
A third identifier is the class name. Class names can be great ways to find content. Class names are not always unique — and occasionally they can point to hidden text. Much of the course goes through these identifiers and helps you understand how to select the right one for your application.
Once you're using identifiers, you start realizing that not everything can be identified uniquely by names. Some names require either using CSS to uniquely identify a part of the DOM, or you can explicitly call relationships using XPATH. Both approaches are even more tied to code and require you to double check the structure for your test after builds that affect the code on which you base identifiers.
I'm not going to go into the details — those are best left for the course. But, suffice to say, you have plenty of identifiers in HTML and CSS to ensure that you can apply inputs to your application and measure the application responses consistently.
Using Identifiers: Codeless and Coded
The final chapter of the course goes into the meat of the topic — actually using identifiers. After you select an identifier, you may test with it. You use identifiers:
- for input fields to create input data.
- for buttons to drive actions and behaviors on the page.
- to validate output fields.
There are two kinds of testing engines. One is codeless and lets the testing engine inspect the DOM and, based on the region in which a user clicks or focuses, find a unique identifier for the text box or button to initiate activity. The other is coded and uses a programming language interface to initiate tests and measure responses, using identifiers from HTML code to control behavior. Coded engines, like Selenium, Appium, Protractor, and WebDriver.IO, use WebDriver. WebDriver is a remote control interface that provides remote control of web browsers.
When codeless tests encounter updated code and identifiers, the new identifiers can cause the codeless tests to fail. Some test engines, like Selenium IDE, try to find multiple locators for a given object, so that a change in one locator is not an immediate failure.
If you're already a programmer, you will feel right at home with coded test engines. You might be able to use your choice of programming language, or a language you know already, to write tests.
Andrew's course goes through two test examples using the DuckDuckGo.com website. The first example he writes in Java, and it describes all the tests he wants to apply, the waits between entering data and getting a response, and then measuring the response. He writes this all out manually in Java. This looks like a script of instructions with locators. As the testing grows, the number of scripts can grow — and the number using the same locator in different places can grow. Which means all the scripts need to change if one locator changes.
If you're a coder, you're probably thinking,
"I bet maintaining this script is a pain in the ..."
Then, Andrew makes all of you developers happy by saying, effectively,
"There is a better way."
Andrew goes through the Page Object Model, which helps separate the test code from the test objects. Effectively, you create a file with class of objects for finding web elements, and either entering data in them or verifying the response. You create a separate class of tests that actually use the elements class and manipulate the tests. So, if the development team updates the page locators, you keep the same test code and simply update the locators.
Huge sigh of relief.
Here is an example of Page Object code in Java from Andrew's course:
One thing the course didn't cover is how Applitools can help. Yes, you can use test code to both apply a test instruction, wait for a response, and measure the result. That's a great way to think about applying tests to web pages.
Of course, even if you test programmatically, you need to make sure that each object on the page is rendered as expected. Different content, unexpected color or visual images, and other visual errors require painstaking coding to ensure they don't haunt your code. That's where Applitools comes in.
Applitools can easily integrate, with both coded and codeless tools, to help take visual images of the output from each test step and compare it with a baseline. While your functional code ensures that your main function behaves as inspected, Applitools is ensureing that everything else behaves equally well.
What I Take Away
Through this post, I want to share with you a taste of what I got from the course. Being some 20 years out of programming, I make all the rookie mistakes of someone new to this field. And, honestly, that sucks. I like being the smartest person in the room (and, yes, I know it's a common failing among engineers — we all want to be that person). But, I'm learning as I go forward.
My takeaways are that there are lots of different identifiers out there to control the behavior of test tools. Not all are created equally. And, not all are created.
A helpful development team will create unique identifiers for each element you might want to test. Those developers who think about testing do so because they are writing the same tests themselves. Those coders moonlighting as test developers might actually be you — as you are a part of the development team yourself, and you're using this course to help build better tests or improve code testability.
You might be finding, too, that you're not as connected with the development team — the coding has been done long before you immerse yourself into the test process. This course helps you write tests even when you write tests independent of the development team.
As always, I get to show how smart I am by adding my certificate of completion:
Thank you for the course, Andrew Knight!
Published at DZone with permission of Michael Battat. See the original article here.
Opinions expressed by DZone contributors are their own.