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
Better toHaveExactText #568
Comments
That would be really nice to have this. I have similar problems by using just |
@matheo do you have any thoughts on this issue? |
@levsim2016 seems legit to have an option to trim these cases, |
This looks to have been addressed in the above PR. Can this be closed now? |
Description
The
toHaveExactText
test is pretty fragile. If I use this HTMLThen I can safely
expect(spectator.query('some-tag')).toHaveExactText('hello')
.However, as soon as
some-tag
gets a ton of new attributes, and then somebody's IDE reformats like so:Then the test fails. I don't think that it should, because what I'm testing is for the text that's visible. In the second example, the DOM returns that string as ' hello ', i.e. there's a single space at the start and end.
I can't use
toHaveText
instead because that does acontains
check, vs. an actual "does this string match". As an example,toHaveText
would return true if the text was actually "Othello" because it's then doing a contains.Proposed solution
Add a second optional parameter to toHaveExactText that specifies whether or not to trim the text. It would of course default to false to prevent any existing code base from breaking.
Alternatives considered
Could have something like
toHaveExactTrimmedText
Do you want to create a pull request?
No
The text was updated successfully, but these errors were encountered: