-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
cy.contains() improvements: normalizing whitespaces, case-sensi… #5653
cy.contains() improvements: normalizing whitespaces, case-sensi… #5653
Conversation
Thanks for the contribution! Below are some guidelines Cypress uses when doing PR reviews.
PR Review ChecklistIf any of the following requirements can't be met, leave a comment in the review selecting 'Request changes', otherwise 'Approve'. User Experience
Functionality
Maintainability
Quality
Internal
|
2222f86
to
3caf09b
Compare
Is it possible this is a breaking change? Could a user have tests that rely on the old behavior and they will fail once this is introduced? Just need to know so that we can hold off on releasing this until the next major version of Cypress. |
@chrisbreiding #2785 doesn't break anything but #92 can be a breaking change. Then, should I change the target branch to |
@sainthkh Yes, breaking changes should target |
Rebased and tests all passed. |
I think the only thing left for this is to update the documentation. @sainthkh Can you open a PR targeting cypress-io/cypress-documentation#1710? Please update the |
|
const normalizeWhitespaces = (elem) => { | ||
let testText = elem.textContent || elem.innerText || $.text(elem) | ||
|
||
if (elem.tagName === 'PRE') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why the exception for pre
tags? I mean, I can kind of get the logic, but it does seem strange to make an exception for a single tag and this not be documented anywhere. I guess that's my concern. Someone opening an issue one day like, 'this is working differently here' and we have this undocumented exception.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pre
tag preserves whitespaces like this:
https://codepen.io/sainthkh/pen/jOEpzmX
So, it is the exception. Because I thought it reflects how browsers work.
Do you think we need a section for this behavior in contains()
documentation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah...probably adding a section in the Notes of the .contains()
doc so that people can find this somehow. There's are other exception notes in there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about elements styled with white-space: pre;
?
We have cases where upgrading to Cypress 4 breaks tests where we're explicitily want to vaildate that the whitespace is present as it is rendered. Should there be a flag allowing override of this behaviour?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- I ran our Dashboard tests through this branch since we have about 1,000 uses of
.contains()
in there. I didn't see anything really strange pop up. It doesn't even seem to be breaking any of our usecases - probably because we've avoided asserting on newlines before. - I functionally tested this on a few examples and it seems to be working as intended.
It feels a bit weird that this test case passes...
// <h1>hello world</h1>
cy.contains(/Hello World/i, { matchCase: true })
Also the exception of the <pre>
tag seems a bit weird as undocumented behavior as mentioned in another comment.
// <h1>hello world</h1>
cy.contains(/Hello World/i, { matchCase: true }) In this case, how about throwing an error?:
|
Now, an error is thrown for |
1b53324
to
ec02a09
Compare
Yah, the 4.0 branch is broken atm, so trying to fix that up to get these tests passing. |
6e28b78
to
a0eddc2
Compare
These 2 are fixed together because the implementation for one can affect the other.
User facing changelog
<pre>
tag.matchCase
option tocy.contains()
.Additional details
Why was this change necessary?
issue #92
issue #2785
We can currently use regex, but in some cases, we need Cypress's out-of-the-box option.
What is affected by this change?
cy.contains()
can do more things like ignoring multiple spaces and case-sensitivity.Any implementation details to explain?
A new
contains
implementation has been added.How has the user experience changed?
PR Tasks
cypress-documentation
? => Cypress issue#92: cy.contains() doc. cypress-documentation#2397type definitions
?~~Have new configuration options been added to thecypress.schema.json
?Documentation and type definition tasks will be started when this PR is ready and reviewed.