-
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
should('have.text', ...) should ignore leading and trailing whitespace #3887
Comments
There's a related feature request here for making |
Recently I added a
|
.text() command proposal: #630 |
It is nice to have the What I did was to add a custom command like: Cypress.Commands.add(
'shouldHaveTrimmedText',
{
prevSubject: true,
},
(subject, equalTo) => {
if (isNaN(equalTo)) {
expect(subject.text()).to.eq(equalTo);
} else {
expect(parseInt(subject.text())).to.eq(equalTo);
}
return subject;
},
); And now I can do: cy
.get('.some-class')
.shouldHaveTrimmedText('whatever'); |
One way to go about it is: cy.get('...').should($el => expect($el.text().trim()).to.equal('...')); |
Yes, cy.get('...')
.text()
.should('equal', 'foo'); |
I also encountered the same issue so I use: cy.get('.message').should('contain.text', message) |
This comment has been minimized.
This comment has been minimized.
The problem with contains is it matches any substring. Given:
Given that the cypress matchers are Chai, I'm not sure if we'd have to extend Chai or cypress to implement this. This seems to work:
I'm not sure how to turn that into a custom command though. |
@loren138 Have you seen these posts? |
We try to keep the number of external packages as low as possible in our project so we can add our own custom commands but are not likely to use third party command packages. This seems to work as a slight modification on #3887 (comment) but I don't think it's as flexible since it doesn't have the jQuery helper, but I can't figure out how to use Cypress.Commands.add(
"shouldHaveTrimmedText",
{ prevSubject: true },
(subject, equalTo) => {
expect(subject.text().trim()).to.eq(equalTo);
return subject;
},
); |
It shouldn't be difficult to copy |
any update? |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
I've been using this as a workaround for the last while and it seems to be working well. I took bits and pieces from comments above and overwrote Just put this into your
|
this worked for me |
any update? |
@todd-m-kemp I used your method (thanks for that!), but I found that |
this works for me but has some typescript issues which I ignore with @ts-ignore. Anyone know how to add the proper types to this? And when will there be an official solution to this? I encountered that issue testing the headline of a site! Having this in one line in my IDE <h1 data-cy="headline">Welcome to mySite</h1> and test it with the following cypress command it('headline should display `Welcome to mySite`', () => {
cy.mount(index)
cy.get('[data-cy=headline]').should('have.text', 'Welcome to mySite')
}) its all working so far... But my editor tends to break that into 3 loc like with eslint and autosave enabled: <h1 data-cy="headline">
Welcome to mySite
</h1> The test will than fail with the following message:
|
any updates? |
This is mostly automatic formatting from djLint (some of which is *weird*, but consistent and occasionally weird formatting is better than no formatting) I've also abstracted a chunky bit of HTML (mostly from an SVG path) into a partial and tried to make the formatting a little more sensible within constraints of djLint acceptability One test is updated. djLint generally prefers using new lines for the inner content of tags - the automatic formatter won't indent the lines it moves down, but it accepts manually indented lines. However, one of these two changes adds a new line character, which then breaks tests that use `have.text` without whitespace[1]. One way around this is to use `contain.text`[2], but then you're not asserting that there isn't any other content. I've opted for trimming then asserting equality (rather than containment)[3], but this might get messy in future. Another option is adding a package that does the whitespace trimming with a simple method[4]/[5], but unless it becomes a recurring theme, I think it's best to avoid adding an extra dependency [1]: cypress-io/cypress#3887 [2]: cypress-io/cypress#3887 (comment) [3]: cypress-io/cypress#3887 (comment) [4]: cypress-io/cypress#3887 (comment) [5]: https://github.com/Lakitna/cypress-commands
May be this will help someone, instead of overwriting should or creating new query, I tested below and its working cy.visit("https://ecommerce-playground.lambdatest.io/"); using to.include will ignore the spaces and compares the containing text |
Wouldn't this also match "aBlogger" ? |
I ran into a problem where cypress is not waiting for the element to update when using this command: So it is better to use the function parameter overload of should, so that cypress waits for the element to have the expected text. Full command: Cypress.Commands.add(
'shouldHaveTrimmedText',
{prevSubject: true},
(subject: JQuery<HTMLElement>, text: string) => {
cy.wrap(subject)
.should(element => expect(element.text().trim()).to.equal(text));
}
); |
Another approach - I didn't want to override functions in all cases, so I defined a
|
If your HTML happens to have whitespace in the tag, e.g.,
<div> foo </div>
, that text will not impact how the user sees the page, unless it is a<pre>
element. I don't think that the'have.text'
assertion should fail just because it found' foo '
when it was expecting'foo'
.If you're not willing to change this (since it is technically a breaking change), maybe there should be a
have.text.trimmed
?Current behavior:
should('have.text', ...)
fails if the HTML contains whitespace, even if that whitespace doesn't impact the rendered content.Desired behavior:
should('have.text', ...)
should ignore leading and trailing whitespace for elements that won't render it. Elements likepre
(and elements with certainwhite-space
css values) should still consider leading and trailing whitespace.Versions
3.2.0
The text was updated successfully, but these errors were encountered: