You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you are on a web page in which there are multiple elements with the same identifier (e.g class attribute name etc) and the ONLY difference is the element text, then you are likely to execute the webdriver's find_elements function and then iterate through the element, checking the text of each element.
There is no easy way to do this in the selenium2library however. The most straight forward way is to write a custom library. However, I think this use case is common enough that adding keywords to the selenium2library would be a good idea
Here's the suggested high level functionality.
keyword that finds and return a list of elements then that could be iterated through. (e.g Find Elements). Would support all the locators.
keyword to filter through a list of given elements and return a specific element. (e.g. Get Element That Has This Text ${string})
Either modify the click element function's interface or create a new one that allows me execute the click function on the element instead of specifying a locator. (e.g Click Element ${element})
If something like this sounds good, I could work on a PR that takes a first cut at this.
@jaloren if you want to create a PR I'll definitely work with you to get it merged in. You may want to take a peek at #356. @emanlove was working on a feature similar to this. It looks like this may be a non-trivial implementation though.
@jaloren The problem you describe is more of a locator problem than one to be solved by grabbing elements and then acting upon them. I personally find CSS class a poor location strategy and if there is no unique id then you might try xpath. There is a lot of tricks you can do with xpath to find elements.
@zephraph If you get a chance can you review #356 and then merge it if you find it satisfactory. I know @ombre42 has been busy lately and I prefer not to merge my own pull request but have them reviewed by someone else.
Hey @emanlove, good to have you back! I've been doing a little house cleaning in your absence, I hope you don't mind too much. If you have any issues just email me.
I'll definitely take a look at it. On the topic of listeners, I'd also like you to look at #365.
Due to actual web UI implementations, especially legacy interfaces built over a decade ago (i have to test such a one), there are many pages that do not have any unique identifiers that can be hooked into with the exception of XPath.
I do not want to use XPath for the following reasons:
the xpath locator id can be (and almost always will be) hideously long, complicated and easy to munge in a test case
xpath is slooooow compared to other locator strategies
its super brittle because the moment the tree changes (i.e anything in the page changes), the xpath breaks
xpath is NOT nor has ever been user friendly, especially when you start playing games with attribute naming. I certainly find it hard to read.
web guis can and do page refreshes that cause the webdriver to barf about a stale element reference. I don't know why this is but it seems to happen a LOT more frequently with xpath location strategy.
Compared to that, I think "get a list of elements based on a comparatively simple id and then look at the text" is simpler, easier to debug, and much easier to maintain. And by maintain, i mean multiple engineers will need to look over, fix/support the test case. The only thing I hate more than writing my own xpath is trying to debug someone elses.
#365 does look promising though its not clear to me whether this would be a good fit for addressing the use case i've described or not. I'd be interested on waiting for that PR to get merged and then take that functionality for a test drive before I do anything with this issue.
I've got a better handle on what you want now. The good news is that we're already working towards this in some ways. @emanlove's #356 PR will allow you to pass in a webelement instead of a locator and have things like click events happen.
EDIT: This PR currently has Get WebElements which is equivalent to Selenium's Find Elements.
@zephraph with #356 combined with Find Element and Find Elements Keywords would be perfect. As you said, I can easily implement custom keywords on top of it to fit my usage.
@jaloren, All this will be doable on the 1.7 release which I hope to have out soon. I'm trying to get #356 merged in today if @emanlove is available, and then there's only a few more things to wrap up before release.
Activity
just-be-dev commentedon Apr 28, 2015
@jaloren if you want to create a PR I'll definitely work with you to get it merged in. You may want to take a peek at #356. @emanlove was working on a feature similar to this. It looks like this may be a non-trivial implementation though.
emanlove commentedon Apr 29, 2015
@jaloren The problem you describe is more of a locator problem than one to be solved by grabbing elements and then acting upon them. I personally find CSS class a poor location strategy and if there is no unique id then you might try xpath. There is a lot of tricks you can do with xpath to find elements.
@zephraph If you get a chance can you review #356 and then merge it if you find it satisfactory. I know @ombre42 has been busy lately and I prefer not to merge my own pull request but have them reviewed by someone else.
just-be-dev commentedon Apr 29, 2015
Hey @emanlove, good to have you back! I've been doing a little house cleaning in your absence, I hope you don't mind too much. If you have any issues just email me.
I'll definitely take a look at it. On the topic of listeners, I'd also like you to look at #365.
jaloren commentedon Apr 30, 2015
@emanlove
Due to actual web UI implementations, especially legacy interfaces built over a decade ago (i have to test such a one), there are many pages that do not have any unique identifiers that can be hooked into with the exception of XPath.
I do not want to use XPath for the following reasons:
Compared to that, I think "get a list of elements based on a comparatively simple id and then look at the text" is simpler, easier to debug, and much easier to maintain. And by maintain, i mean multiple engineers will need to look over, fix/support the test case. The only thing I hate more than writing my own xpath is trying to debug someone elses.
jaloren commentedon Apr 30, 2015
#365 does look promising though its not clear to me whether this would be a good fit for addressing the use case i've described or not. I'd be interested on waiting for that PR to get merged and then take that functionality for a test drive before I do anything with this issue.
just-be-dev commentedon May 1, 2015
I've got a better handle on what you want now. The good news is that we're already working towards this in some ways. @emanlove's #356 PR will allow you to pass in a webelement instead of a locator and have things like click events happen.
EDIT: This PR currently has
Get WebElementswhich is equivalent to Selenium'sFind Elements.jaloren commentedon May 2, 2015
@zephraph with #356 combined with Find Element and Find Elements Keywords would be perfect. As you said, I can easily implement custom keywords on top of it to fit my usage.
I'll reduce the scope of this issue accordingly.
[-]Support Keyword for Finding and Manipulating Multiple Elements[/-][+]Support Keyword for Finding Elements[/+]emanlove commentedon May 2, 2015
@jaloren Good arguments as to why not to use xpath.
What is the difference between Get WebElements and Find Elements? Not sure I see the difference...
just-be-dev commentedon May 2, 2015
@emanlove, they're the same thing, I just forgot they existed when I was writing that. ^_^
just-be-dev commentedon May 11, 2015
@jaloren, All this will be doable on the 1.7 release which I hope to have out soon. I'm trying to get #356 merged in today if @emanlove is available, and then there's only a few more things to wrap up before release.
just-be-dev commentedon May 19, 2015
#365 is merged!