react-select-event results in very long-running tests

[joeykmh]

First of all thank you very much for this library, it simplifies testing with react-select immensely!

Recently I rewrote many of our old tests using react-select-event, but noticed that test runtime went up by a factor of 5 or more. On my local machine tests are taking 5-12 seconds to run, on CI servers up to 30 seconds. This adds up quickly!

We're using formik and react-select for both single and multi-select dropdowns.

Here is a distilled example of one such test:

it("submits the correct values", async () => {
  const submitStep = jest.fn();

  const values = {
    name: "ACME corporation",
    industries: "Finance",
    city: "Berlin",
    country: "Deutschland",
    postalCode: "10000",
  };

  render(
    <CompanyNameAndIndustry
      submitStep={submitStep}
      initialValues={{
        name: "",
        industries: "",
        city: "",
        country: "",
        postalCode: "",
      }}
    />
  );

  userEvent.type(screen.getByLabelText("Name des Unternehmens*"), values.name);
  await selectEvent.select(screen.getByLabelText("Branche"), values.industries);
  userEvent.type(screen.getByLabelText("Ort*"), values.city);
  userEvent.type(screen.getByLabelText("Postleitzahl*"), values.postalCode);
  await selectEvent.select(screen.getByLabelText("Land"), values.country);
  userEvent.click(screen.getByText("Weiter"));

  await waitFor(() => expect(submitStep).toHaveBeenCalledWith(values));
});

When I remove the selectEvent.select() calls, the runtime goes back down to <1 second.

My questions:

• Is there anything obvious that I'm doing wrong here?
• Is it expected that tests should take drastically longer?
• Is there any way to optimize this?

[Pegase745]

We're experiencing the same behavior on our test suites 😕

[joeykmh]

@Pegase745 sorry to hear that! FYI I have not found a solution yet. Right now we're just not testing react-select inputs inside of formik because it blows up our test pipelines.

[Pegase745]

@josephkmh what's weird in our case, is that by simply installing the library, our test suite fails

[romgain]

Hi both!

This is an issue I have also noticed, but I unfortunately haven't found a solution yet.
Please do let me know if you find anything that could help or if you'd like to contribute a solution!

Thanks!

[lukaszwnek]

@Pegase745 Hello! That's exactly the problem I bumped into. For me, it looks that somehow the testing library's configure call gets ignored (overwritten?). I had the following code in my runner.js file:

import { configure } from "@testing-library/dom"; 
configure({ testIdAttribute: "data-test" })

After installing react-select-event, the testing library starts using the default test id attribute: data-testid, and this, in turn, results in multiple fails like the following:

TestingLibraryElementError: Unable to find an element by: [data-testid="switch-label"]

Hope this helps to identify the underlying issue. Cheers!

[Pegase745]

Interesting @lukaszwnek, though with a waitFor it eventually finds the required element. It simply feels like there's a race condition being triggered somewhere 😕

[lukemorales]

@Pegase745 Hello! That's exactly the problem I bumped into. For me, it looks that somehow the testing library's configure call gets ignored (overwritten?). I had the following code in my runner.js file:

import { configure } from "@testing-library/dom"; 
configure({ testIdAttribute: "data-test" })

After installing react-select-event, the testing library starts using the default test id attribute: data-testid, and this, in turn, results in multiple fails like the following:

TestingLibraryElementError: Unable to find an element by: [data-testid="switch-label"]

Hope this helps to identify the underlying issue. Cheers!

@lukaszwnek I believe that your case is yet another issue to be resolved. With @Pegase745 and I, we use the default data-testid field so there's definitely another issue causing our race condition as Michel said