Jest-dom: toHaveDisplayValue checks for substring rather than equality when passed string value?

[asokoloski-m]

• @testing-library/jest-dom version: 5.10.0

Relevant code or config:

  render(<select data-testid="displayvalue">
    <option value="null"></option>
    <option value="choice" selected>Choice 1</option>
    </select>
    );
  expect(screen.getByTestId("displayvalue")).toHaveDisplayValue(""); // Passes?
  expect(screen.getByTestId("displayvalue")).toHaveDisplayValue(/^$/); // Fails

Hi, I'm not sure if this is a bug, but it was pretty surprising behavior to me, and took a while to figure out. It seems like the toHaveDisplayValue assertion doesn't do an exact match if you pass a string as the expected value, but an "includes" match. If you want to check that the display value of an element is empty, for example, you have to use a regular expression, as shown above. (The test is designed to fail)

It also looks like before regular expressions were supported in .toHaveDisplayValue, it did do an exact match (though I have not tested this, only looked at the code changes). It seems to me more intuitive that when passed a string, it should check for a full exact match, especially since that's how .toHaveValue works. Thoughts? Thank you!

Example code in a sandbox:

https://codesandbox.io/s/react-testing-library-demo-forked-g5udj?file=/src/__tests__/hello.js

[nickmccurdy]

I just tested this on 840414f (#223 squashed) and you're right, it was using an exact match. Since 5c9e8e5 (#242 squashed) it's been an inexact match. As far as I'm understanding the intent compared to toHaveValue, this does seem like a regression.

[nickmccurdy]

I looked into fixing this, and #242 is using the matches util function, which performs non-exact matches on strings and regexps. The problem is that if I make it exact for strings, it would be inconsistent if it wasn't exact for regexps, but regexps usually aren't exact as people would explicitly use markers (such as $, ^, \A, and \Z). Any thoughts on how we should approach this?

[asokoloski-m]

Hmm, I think the behavior in toHaveDescription is pretty much what I was imagining. Here's the snippet of relevant logic (it's just inline, not factored out into a function):

    ...
    checkWith instanceof RegExp
        ? checkWith.test(description)
        : this.equals(description, checkWith)
    ...

That's what fits my intuition, at least. It is inconsistent in the way you describe, but I agree that with a RegExp you have an easy option to anchor at the beginning and end, so I don't think it's a big problem.

Also, looking at the documentation, it kinda implies that this is the way it should behave, because all of the examples where a string is passed seem to be using the entire expected display value, not a substring:

expect(input).toHaveDisplayValue('Luca')
expect(input).toHaveDisplayValue(/Luc/)
expect(textarea).toHaveDisplayValue('An example description here.')
expect(textarea).toHaveDisplayValue(/example/)
expect(selectSingle).toHaveDisplayValue('Select a fruit...')
expect(selectSingle).toHaveDisplayValue(/Select/)
expect(selectMultiple).toHaveDisplayValue([/Avocado/, 'Banana'])

[kiripeti]

I also face with this behaviour. In my test the following three passes:

expect(input).toHaveValue('1995.12.17 00:00');
expect(input).toHaveDisplayValue('1995.12.17');
expect(input).toHaveDisplayValue('12.17');

IT is not the thing I would suppose.

[nickmccurdy]

@kiripeti To be clear, do you expect the first line to pass and the last two to fail?

[Kjir]

I was also very surprised to discover this behaviour and I've been puzzled for quite a long time. I wanted to check that after I click on the delete button my form values are cleared and to my surprise the following test (written first) passed:

expect(getByLabelText('Connnection name')).toHaveDisplayValue("");

Especially when using testing library the behaviour is unexpected: if I try to do getByText('Select') it will not match the Select a fruit... text. I believe the behaviour here should be consistent with that of testing library: https://testing-library.com/docs/dom-testing-library/api-queries#textmatch

[github-actions[bot]]

:tada: This issue has been resolved in version 5.11.7 :tada:

The release is available on:

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

Your semantic-release bot :package::rocket: