Skip to content

Support Keyword for Finding Elements #377

Closed

Description

@jaloren

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.

  1. keyword that finds and return a list of elements then that could be iterated through. (e.g Find Elements). Would support all the locators.
  2. keyword to filter through a list of given elements and return a specific element. (e.g. Get Element That Has This Text ${string})
  3. 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.

Activity

  1. just-be-dev commented on Apr 28, 2015

    @just-be-dev
    Contributor

    @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.

  2. emanlove commented on Apr 29, 2015

    @emanlove
    Member

    @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.

  3. just-be-dev commented on Apr 29, 2015

    @just-be-dev
    Contributor

    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.

  4. jaloren commented on Apr 30, 2015

    @jaloren
    Author

    @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:

    1. the xpath locator id can be (and almost always will be) hideously long, complicated and easy to munge in a test case
    2. xpath is slooooow compared to other locator strategies
    3. its super brittle because the moment the tree changes (i.e anything in the page changes), the xpath breaks
    4. 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.
    5. 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.

  5. jaloren commented on Apr 30, 2015

    @jaloren
    Author

    #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.

  6. just-be-dev commented on May 1, 2015

    @just-be-dev
    Contributor

    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.

  7. added this to the milestone on May 1, 2015
  8. jaloren commented on May 2, 2015

    @jaloren
    Author

    @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.

  9. changed the title [-]Support Keyword for Finding and Manipulating Multiple Elements[/-] [+]Support Keyword for Finding Elements[/+] on May 2, 2015
  10. emanlove commented on May 2, 2015

    @emanlove
    Member

    @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...

  11. just-be-dev commented on May 2, 2015

    @just-be-dev
    Contributor

    @emanlove, they're the same thing, I just forgot they existed when I was writing that. ^_^

  12. modified the milestones: 1.7, on May 11, 2015
  13. just-be-dev commented on May 11, 2015

    @just-be-dev
    Contributor

    @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.

  14. just-be-dev commented on May 19, 2015

    @just-be-dev
    Contributor

    #365 is merged!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions