Redacted
Redacted

Reputation: 633

programmatically finding locators for webelements for selenium

What I'm doing

I'm new to Selenium and trying it out because my boss might have projects I can work on if I get proficient at using Selenium to test our company web aplications. I did some research to identify the main problems that afflict webtesters using Selenium and one of them is reliably finding locators for webelements easily. To rememdy this and make my life easier I've set up a simple program to take in locators (xpath,className, ect) and try each one of them iteratively.

Whats the problem then?

Now that I've got a good solution for trying each possible locator once I have them, I need a quick (preferably less manual) way to obtain these locators. Up till now I've been using the f12 chrome developer tool to inspect the webelements and then manually copy paste the relevant information into the method:

Webdriver driver = new Webdriver; driver.findelement(By.id("id was pasted here"));

However finding the ids and things manually and having to read all that HTML stuff is hard and quite confusing since I haven't really delved into web design all that much so Javascript CSS XML and HTML are relatively new to me. I know some of the (very) basics but I couldn't find my way around a well designed website.

What I want

is to be able to click something like "inspect element" and be greeted with a list of locators for that webelement. Usually the easiest way for me is to rightclick on the highlighted HTMl for that element and select "copy Xpath" but xpath expressions that are auto generated aren't always the best for locating elements. I found a similar question that deals with this issue here:

Selenium 2 : finding web element locators programatically

However that question doesn't fit my needs because it's more specific into flexible xpath locators and doing everything purely programatically. Also the answer provided was "use the developer tools" and "no there are no other tools". I'm willing to try my hand at making a simple tool but I need to know where to start first. What I desire is a simple way to click or otherwise select/ programmatically log a webelement's locators and/or get a simple message box that finds me possible ids, locators, classnames, possible xpaths in a list ect. I want to do this so I can just copy paste the text from that message box or log message into the code that needs to identify the webelement.

Good idea but where do I start?

My problem is I have no idea where to start with this. I think I would have to learn of some way to program to my mouse and then learn HTML enough so I could parse out the locators but I need guidance because that is way to broad and is likely not actually what I need. So hence I ask, what do I need to learn/do in order to be able to see all the possible locators of a webElement all at once easily. I am open to suggestions about how I might learn/create a simple tool that would help me (and probably a lot of other people) overcome this problem.

Upvotes: 1

Views: 1809

Answers (1)

Julian
Julian

Reputation: 1685

To a degree, the only way you'll get your hands on quality locators is to hand craft them. There are plenty of css selector generator tools out there in the form of browser extensions that let you click elements and get an autogenerated locator in the form of css or xpath. Big but though, you end up getting very verbose and brittle selectors through methods like this.

Those tools are definitely useful, however, because you can take what it gives you as a baseline and then start whittling away until it becomes the level of verbosity you need, while relying on as few unrelated elements as possible. In a best case, you can use firefox's or chrome's element inspector tool to fast-travel to an element in the DOM, and if your element uses a unique attribute like id, then that's often all you need. (You can easily test your locators with the javascript console if the app uses jquery by doing one of $("locator") $$("locator") $j("locator") depending on your jquery version)

While figuring out your locators never stops being annoying, it becomes much easier and in my opinion will boost your productivity in the long run because locators that work now can and will occasionally stop working as the app under test undergoes dev revisions, and finding out what about it is different can be a debugging challenge in it's own. So part of minimizing the occurrence of your locators breaking due to changes in the app under test is getting comfortable manually inspecting the dom and creating locators that are as locationally independent as possible. And what I mean by locationally independent is by targeting attributes that won't change, and by not relying on element hierarchy or sibling element's ordinal value (in the case of list items) which can change as a UI gets revised.

Every element you rely on to locate your target is a liability and contributes to the brittleness of your overall locator, it's impossible to avoid this completely though. That human touch is what lets you be as verbose as you need, while being as concise as possible to have a robust and functional locator

Upvotes: 1

Related Questions