Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Verify string regardless of case #849

Closed
rubygeek opened this issue Jul 13, 2017 · 7 comments · Fixed by #1043
Closed

Verify string regardless of case #849

rubygeek opened this issue Jul 13, 2017 · 7 comments · Fixed by #1043

Comments

@rubygeek
Copy link
Contributor

I have a two websites that I want to verify with the same code. Problem is one website the disclaim is in ALL CAPS and one is lowercase. Example

Use of this site constitutes acceptance of our

USE OF THIS SITE CONSTITUTES ACCEPTANCE OF OUR

So i propose the following api change:

Element Should Contain    locator, expected, message= 

to

Element Should Contain    locator, expected, case_sensitive=True, message=

Default of course being True to avoid breaking changes and when the developer wants case insensitive, they can pass case_sensitive=False

I am willing to make these changes and submit a PR if it might be approved.

@aaltat
Copy link
Contributor

aaltat commented Jul 13, 2017

The idea sounds good. Although I have nagging feeling, in my head, that there was something that which denies doing this. But because I can not remember what that nagging feeling is, perhaps it is not important.

From the API point of view, it would be more backwards compatible if the API would work like this:

| Element Should Contain | locator | expected | message='' | case_sensitive=True |

Also there would be other keyword which would benefit from the same kind functionality (assuming that my nagging feeling does not prevent the implementation), like Element Should Not Contain, Element Text Should Be, Wait Until Element Contains, Wait Until Element Does Not Contain, Wait Until Page Contains and Wait Until Page Does Not Contain. If you can find an implementation for a one keyword, would you be willing to enhance other keywords too?

@rubygeek
Copy link
Contributor Author

Yes, I'd be happy to make this consistent across related keywords.

@pekkaklarck
Copy link
Member

pekkaklarck commented Jul 13, 2017

This would be handy but can be surprisingly big task:

Instead of adding case-insensitivity support to S2L, it would be possible to use its getter keywords (e.g. Get Title) in combination with BuiltIn keywords that support case-insensitivity. If case-insensitivity in the lib is seen valuable enough to be implemented, it should preferably use same ignore_case=False argument as BuiltIn.

@aaltat
Copy link
Contributor

aaltat commented Jul 13, 2017

Although selenium does not support it might be possible to do with xpath: https://stackoverflow.com/questions/2893551/case-insensitive-matching-in-xpath . If it does not work with xpath, then with those element related keywords, it is easy get the text and convert it to lower/upper case. Then with page related keyword the performance hit may be too high if we do not it working with xpath (sorry for ruining the fun of finding all this stuff).

Yes documenting and testing is big task, but it should not prevent us doing it.

Good reminder from Pekka that having consistent arguments would be good idea, ignore_case=False then it is.

@rubygeek
Copy link
Contributor Author

I'm working on this currently and including more functions than Element Should Contain

@apuchkov
Copy link

PR for #1043 only added case_sensitive parameter to the Element Should Contain and Element Should Not Contain keywords, but not to Wait Until Element Contains, Wait Until Page Contains and others.

Should we reopen this ticket or create a new one?

@aaltat
Copy link
Contributor

aaltat commented Nov 18, 2019

Please create a new ticket, we use tickets to track what is in the next release and generate base for the release notes.

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

Successfully merging a pull request may close this issue.

4 participants