Feature Request - New keyword to perform operation elements returning from Get Webelements

[aliasgerkw]

Can we have a keyword wrapped around Get Web Elements which will do operations on the list return by this? For example, If in an application I filtered a column and want to verify if the results are there in each row I can simply do below:

@{elList} = Get webelements ${OR_CELL_TO_CHECK}
:FOR ${item} IN @{elList}
${textOfAcc}= Get Text ${item}
Should Be Equal ${textOfAcc} ${SHOULD_CONTAINS}
END

We can have multiple keywords using this like:
Get elements and verify the text
Get elements and verify attribute
Get elements and verify does not contains text

For elements with text we can still use Page Should Contains Text with limit argument as suggested by @aaltat in another thread but I would still feel attribute checks are required some time and we should have a list of keywords to deal with it.

Thanks!

[aaltat]

So you want to do verifications on multiple elements by using a single keyword and by using single selector. Example if one have:
| Element Should Contain | xpath://p | Some Heading |
And if the xpath matches to one or more elements, you would like to verify the text from all elements. Did I understand your request correctly? Instead of creating new keywords, I think it would be better to enhance existing keywords to support such need by adding an argument that is the check done for the first element (the current functionality and must remain as the default) or is the check done for all elements found by the locator.

[aliasgerkw]

Yes @aaltat you got me correct.

Enhancing existing keyword functionality will suffice as well.

[aaltat]

We could consider changing the keyword signature to contain new argument first_element (the argument name needs thinking and that is just initial idea). Then currently:
| Element Should Contain | locator | expected | message | ignore_case | would change to
| Element Should Contain | locator | expected | message | ignore_case | first_element |. Also the first_element default value would be True and it would work in same way as currently. If first_element would be false, then it would check all elements found by the locator, not only the first one. Keyword would fail if zero elements is found and ignore_case would work in same way in both cases.

For consistency reason this should be done to all Element Should... keywords, also to the Element Should Not... keywords. @aliasgerkw are you willing to create PR(s) for making the change possible?

[aliasgerkw]

@aaltat This holds good if we are checking only text, what about checking attribute? Also why this change needed for all 16 keywords containing "Element Should..."?
I was thinking to have a keyword like
Elements Should Match | locator | expected value | message | ignore_case | only_first_element | is_checking_text | which_attribute_if_text_false

is_checking_text will be true to use Get Text, false to Get Element Attribute
which_attribute_if_text_false is mandatory if is_checking_text is false and required attribute name, none if is_checking_text is true.

I would love to contribute and Raise PR for this change if we are on same page.

[pekkaklarck]

This is very highly related to #978.

[aliasgerkw]

@pekkaklarck @aaltat #978 is still open, what do you guys prefer here.

[aaltat]

Yes, #978 and this issue are related but they do not need to be solved in the same PR. The important thing is to remember that when solving this issue, we do not close the door for implementing the #978 It would be nice to solve both in the same release, but they do not need solved by same person. But @pekkaklarck is correct that if decide to make this enhancement, also solving the #978 comes more important.

Unfortunately it is impossible to tell before hand, what solutions would prevent implementing the #978 Also I haven not tough deeply how one could implement #978 but most likely I would add a new argument to the ElementFinder find which would perform the logging. The hard part is to go trough all the keywords and decide when the warning should be displayed and when it should not be displayed.

[flowrean-marcus]

@aaltat I could work on this enhancement, I think, is that okay?

[aaltat]

I have not seen anyone doing work with this, what kind of design you did have in your mind?

[flowrean-marcus]

Exactly what you've been discussing above

If first_element would be false, then it would check all elements found by the locator, not only the first one. Keyword would fail if zero elements is found and ignore_case would work in same way in both cases.