Performance issues with `userEvent.type()`

• @testing-library/user-event version: 12.6.0
• Testing Framework and version: @testing-library/react version 11.2.1
• DOM Environment: jsdom version 16.4.0

Relevant code or config:

describe("demo", () => {
  const text = "2001:db8:ac10:fd01::20";

  test("time type", () => {
    render(<input data-testid="input" type="text" />);
    const input = screen.getByTestId('input');
    const before = new Date();
    userEvent.type(input, text);
    console.log(`type took ${new Date() - before}ms`);
    expect(input.value).toEqual(text);
  });

  test("time delayed type", async () => {
    render(<input data-testid="input" type="text" />);
    const input = screen.getByTestId('input');
    const before = new Date();
    await userEvent.type(input, text, {
      delay: Number.MIN_VALUE,
    });
    console.log(`delayed type took ${new Date() - before}ms`);
    expect(input.value).toEqual(text);
  });

  test("time paste", () => {
    render(<input data-testid="input" type="text" />);
    const input = screen.getByTestId('input');
    const before = new Date();
    userEvent.paste(input, text);
    console.log(`paste took ${new Date() - before}ms`);
    expect(input.value).toEqual(text);
  });
});

Problem description:

Running the above test suite with yarn test --no-cache logs the following values on my machine:

type took 29ms
delayed type took 63ms
paste took 1ms

The results are fairly consistent between reruns (plus-minus a few ms).

The performance difference is starker with longer strings: replacing the input text with const text = "2001:db8:ac10:fd01::20".repeat(100);, the results are as follows:

type took 1380ms
delayed type took 5940ms
paste took 1ms

I understand that some of this difference stems from the letter-by-letter nature of type() which is crucial for certain test scenarios. For the time being however, type() is too slow for many of the tests we run and we’ve had to opt for paste() instead.

I haven’t profiled type()'s internals so I don’t know what the source of the performance penalty is.

[Etheryte]

I don’t think the scale of the problem is as low as you make it to be. If you do ten type() calls within one test you’re already getting close to a second and with anything larger you can quickly reach Jest’s default timeout of 5 seconds. Choosing to not look into this is fair, but I don’t think downplaying the problem is beneficial.

For context, in a perfect world I would expect type() with no delay to be on the same scale as paste(), or at least in the same order of magnitude. Right now it can be several orders of magnitude slower, easily reaching the default time limit.

[ph-fritsche]

@mnbroatch Thanks for your feedback. Have you tried turning it off and on again?

Your detailed information about the environment will certainly allow us reproduce the problem and fix it for you. We’ll be working day and night on this.