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.

Sign up for GitHub

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

Jump to bottom

cy.contains('xxx').should('not.exist') try to expect <body> not to exist in the DOM #14861

Closed
aNyMoRe0505 opened this issue Feb 2, 2021 · 8 comments · Fixed by #17477
Closed

cy.contains('xxx').should('not.exist') try to expect <body> not to exist in the DOM #14861

aNyMoRe0505 opened this issue Feb 2, 2021 · 8 comments · Fixed by #17477
Labels
existing workaround pkg/driver This is due to an issue in the packages/driver directory type: breaking change Requires a new major release version type: bug type: unexpected behavior User expected result, but got another

Comments

@aNyMoRe0505
Copy link

aNyMoRe0505 commented Feb 2, 2021 •
edited

Current behavior

I try to test input validation by cypress
When user enter page first time, user should not see the error message
So I write test like this
cy.contains('forgot_password_error_email_empty').should('not.exist');
but it seems that command try to expect body not to exist in the DOM so it fails in the end

2

When I reproduced my problem, I found this bug is related to next-i18n and only occur in next production build
If I have translation key test (public/static/locales/en) cy.contains('test').should('not.exist') will check body exist or not

If I write cy.contains with selector cy.contains('span', 'test').should('not.exist'), the test will pass.
But I think this is not the good solution.

Desired behavior

cy.contains should not check the body

Test code to reproduce

clone this project (https://github.com/aNyMoRe0505/next-cypress)
npm install => npm run build => npm run start
then npm run cypress:open to execute test

if you run in dev mode (npm run dev) everything works fine.

Versions

"cypress": "^6.3.0"
@aNyMoRe0505 aNyMoRe0505 changed the title cy.contains('xxx').should('not.exist') try to expect <body> not to exist in the DOM cy.contains('xxx').should('not.exist') try to expect <body> not to exist in the DOM (updated: 2021/02/03) Feb 3, 2021
@aNyMoRe0505 aNyMoRe0505 changed the title cy.contains('xxx').should('not.exist') try to expect <body> not to exist in the DOM (updated: 2021/02/03) cy.contains('xxx').should('not.exist') try to expect <body> not to exist in the DOM Feb 3, 2021
@jennifer-shehane
Copy link
Member

I can recreate this issue with the repo provided.

Screen Shot 2021-02-03 at 2 32 11 PM

@jennifer-shehane jennifer-shehane added type: bug stage: ready for work The issue is reproducible and in scope pkg/driver This is due to an issue in the packages/driver directory labels Feb 3, 2021
@egucciar
Copy link
Contributor

egucciar commented Mar 9, 2021

I ran into this on my Next app, found that cy.contains matches the body when used in combination with Next's getStaticProps which prints out static prop data in a <script> tag to the dom for Rehydration.

To fix, as a work around, i can no longer rely on cy.contains to retrieve elements based on text.

suggestion solution would be to exclude script tags from which cy.contains matches/works against.

@sainthkh sainthkh mentioned this issue Mar 19, 2021
Closed
1 task
@cypress-bot cypress-bot bot added stage: work in progress and removed stage: ready for work The issue is reproducible and in scope labels Mar 19, 2021
@sainthkh
Copy link
Contributor

sainthkh commented Mar 22, 2021 •
edited

By default, cy.contains returns <body> when the text you're finding is in <script> or <style> tag. The workaround is to use match command like below:

cy.contains('xxx').should('match', 'body');

You might ask, "can't we just ban the body tag?" Unfortunately, the problem isn't that simple because <body> is sometimes the answer.

Maybe adding ignoreBodyTag option might be the answer. But it's not something I can decide.

@sainthkh sainthkh added existing workaround stage: ready for work The issue is reproducible and in scope and removed stage: work in progress labels Mar 22, 2021
@cypress-bot cypress-bot bot added stage: icebox and removed stage: ready for work The issue is reproducible and in scope labels May 25, 2021
@Nikoms
Copy link

Nikoms commented Jun 9, 2021

We have exactly the same issue. We are moving from react to nextjs et our cypress tests are broken because of this. We are using the workaround, but is there something else planned for this? :)

Thank youuu

@Nikoms
Copy link

Nikoms commented Jul 16, 2021

@sainthkh do you know what "icebox" mean? :D

@sainthkh sainthkh mentioned this issue Jul 19, 2021
Closed
@sainthkh sainthkh added stage: ready for work The issue is reproducible and in scope type: breaking change Requires a new major release version type: unexpected behavior User expected result, but got another and removed stage: icebox labels Jul 19, 2021
@jennifer-shehane
Copy link
Member

@Nikoms It means this work is not prioritized for the Cypress team to work on.

@sainthkh sainthkh mentioned this issue Jul 26, 2021
Merged
1 task
@cypress-bot cypress-bot bot added stage: work in progress stage: needs review The PR code is done & tested, needs review and removed stage: ready for work The issue is reproducible and in scope stage: work in progress labels Jul 26, 2021
@cypress-bot cypress-bot bot removed the stage: needs review The PR code is done & tested, needs review label Aug 4, 2021
@cypress-bot
Copy link
Contributor

cypress-bot bot commented Aug 4, 2021

The code for this is done in cypress-io/cypress#17477, but has yet to be released.
We'll update this issue and reference the changelog when it's released.

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Nov 10, 2021

Released in 9.0.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v9.0.0, please open a new issue.

@cypress-bot cypress-bot bot locked as resolved and limited conversation to collaborators Nov 10, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
existing workaround pkg/driver This is due to an issue in the packages/driver directory type: breaking change Requires a new major release version type: bug type: unexpected behavior User expected result, but got another
Projects
None yet
Milestone
No milestone
6 participants
@Nikoms @chrisbreiding @jennifer-shehane @egucciar @sainthkh @aNyMoRe0505