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

*ByDisplayValue is not finding an input after it changes #1232

Open
stuartbrussell-intuit opened this issue May 9, 2023 · 2 comments
Open

*ByDisplayValue is not finding an input after it changes #1232

stuartbrussell-intuit opened this issue May 9, 2023 · 2 comments

Comments

@stuartbrussell-intuit
Copy link

stuartbrussell-intuit commented May 9, 2023 •
edited

  • @testing-library/jest-dom version: 5.16.5
  • react and react-dom version: 16.13.1
  • jest version: 27.0.1
  • node version: 14.21.1

Relevant code or config:

  it.only('should format typed value', () => {
    renderComponent({ maximumAmount: '100' }); // this is a custom method that renders an input with default values
    await userEvent.tripleClick(screen.getByDisplayValue('0.00'));
    await userEvent.keyboard('55.7');
    await userEvent.tab(); // on blur, the component reformats its value to '55.70'
    expect(screen.getByDisplayValue('55.7')).toBeInTheDocument();   // this works (it shouldn't)
    expect(screen.getByDisplayValue('55.70')).toBeInTheDocument(); // this doesn't work (it should)
  });

What you did:

I'm testing an internally built component that's based on a DOM input. One of it's functions is to format a number according to currency after a blur. E.g. if you type '55.7' and tab out, it will change its value to '55.70'. The field is first rendered with the value '0.00'.

What happened:

The first getByDisplayValue('0.00') works, and that allows us to send events to the element.
But after we type '55.7' and tab out, neither getByDisplayValue('55.70') nor findByDisplayValue('55.70') can find the element. When they fail, here is the output:

Unable to find an element with the display value: 55.70.

Ignored nodes: comments, script, style
<body>
  <div>
    <div>
      <div
        class="idsTSTextField moneyText TextFieldWrapper"
        style="width: 12rem;"
      >
        <label
          class="TFLabelWrapper"
          for="idsTxtField1"
        >
          <span
            class="idsT body-3 intuit light"
            theme="intuit"
          />
          <div
            class="TFInputWrapper"
          >
            <input
              aria-invalid="false"
              aria-label="Money Text"
              class="idsF TFInput intuit light TFNoErrorText TFNotDisabled TFInputHideArrows"
              id="idsTxtField1"
              type="number"
              value="55.70"
              width="12rem"
            />
          </div>
        </label>
        <div
          class=""
        />
      </div>
    </div>
  </div>
</body>

You can see that the input has the value '55.70' as expected.

In a browser with real user events, the input properly shows '55.70'. And in this unit test, the input ends with the correct value, as you can see by the output above.

Instead, getByDisplayValue('55.7') and findByDisplayValue('55.7') both work, i.e. with the typed value instead of the re-formatted value after blur.

Reproduction:

I'm hoping there's an easy answer... 🙄

Problem description:

We can't unit test this part of our component's behavior.

Suggested solution:

Hope for the best?
@stuartbrussell-intuit
Copy link
Author

stuartbrussell-intuit commented May 11, 2023 •
edited

Found a workaround

Instead of:

  it.only('should format typed value', () => {
    renderComponent({ maximumAmount: '100' });
    // ...
    expect(screen.getByDisplayValue('55.70')).toBeInTheDocument();
  });

use:

  it.only('should format typed value', () => {
    const { container } = renderComponent({ maximumAmount: '100' });
    // ...
    /* eslint-disable-next-line testing-library/no-container */
    expect(container.querySelector('[value="55.70"]')).not.toBeNull();`
  });

@MatanBobi
Copy link
Member

Is there any chance that there's something async going on there?
Did you try wrapping the assertion in a waitFor?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@MatanBobi @stuartbrussell-intuit