`toHaveDisplayValue` doesn't support regex

[zikaari]

expect(userSelect).toHaveDisplayValue(/bezos/i) doesn't work, instead it converts /bezos/i to string and tries to do a literal string match, as seen in the error:

    Expected element to have display value:
      /bezos/i
    Received:
      bezos

I'd like to stick with regex because the way we format HTML, it creates leading and trailing whitespaces, which prevent the match.

	<option>
		{{u.name}}
	</option>

It won't be very pretty to have tests that look like expect(userSelect).toHaveDisplayValue(" bezos "), ugly and error prone.

[gnapse]

Sounds good to me. Clearly something we missed the first time around.

[lourenci]

@NeekSandhu are you going for it? I can handle that if you aren't.

[zikaari]

Please take over, you're probably closer to the codebase than I am :)

[gnapse]

🎉 This issue has been resolved in version 5.7.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[zikaari]

sorry should've looked around before, but shouldn't matchers also implement normalization mechanism or are the strict by design?

https://testing-library.com/docs/dom-testing-library/api-queries#normalization

Keeping my OP in mind, shouldn't toHaveDisplayValue('bezos') match " bezos ", because HTML does add leading/trailing whitespaces quite naturally.

[gnapse]

Not sure about that because it also applies to <input type="text" value=" bezos " /> which is not the same as <input type="text" value="bezos" />.

[zikaari]

Yea, I though so too, so just made a helper:

export const ignoreWrappingSpaces = (str: string) => RegExp(String.raw`^\W*${str}\W*$`);

Works good, still keeps the match strict besides leading/trailing whitespaces:

expect(userSelect).toHaveDisplayValue(ignoreWrappingSpaces('bezos'))

[gnapse]

But isn't it the point of this PR that you do not need that anymore? You can use the regex right in there as an argument.

Also we could use jest partial matching helpers:

expect(element).toHaveDisplayValue(expect.stringContaining("bezos")`)

(not sure right now if this matcher supports it, if not we should add support for it if not)

[zikaari]

We still leverage regexes (thanks to the patch), but here's the meat of the util in question:

keeps the match strict besides leading/trailing whitespaces

stringContaining does a partial match, which means we can't prevent someone accidentally adding rogue text (like 1. bezos or something), we strictly want it to be just bezos

[gnapse]

Oh yes, sure. I didn't mean the mention of the stringContaining as a solution to your specific problem, but as an added info of the possibilities. BTW, there's also excect.stringMatching which may indeed have it solved without this patch even.

Anyway, the regex now takes care of that. Glad you have it solved now without the helper.