Extremely slow test performance with userEvent.type - things to look for for a cause?

[joeattardi]

I know there have been issues filed against this project regarding the performance of type. I am not necessarily trying to re-open that debate but I am encountering major issues with tests timing out etc.

I have a pretty straightforward form component with controlled inputs. I have two tests that fill out the form - one using userEvent.type (the latest version) and the other using the lower-level fireEvent.change.

I mostly understand the difference in the two approaches - and that userEvent is preferred - but the test performance hit is stark:

• fireEvent.change approach: 111ms
• userEvent.type approach: 1235ms

This is a particularly large app and with some other forms we have issues with tests timing out or taking far too long because of this.

In both cases, from my understanding, the component's inner workings are being exercised. The form has the correct values and the mock network request is made with the correct data.

I don't see any obvious cause for the major difference in performance. So I have two questions...

(1) Any particular patterns to look for that might explain what, in our code, is causing the performance issue with userEvent.type?
(2) Are there any scenarios where it is considered "sufficient" to use fireEvent.change?

In the case of a form with text fields, what is the advantage of userEvent.type that makes this performance cost worth it?

[ph-fritsche]

I don't see any obvious cause for the major difference in performance.

The two APIs might seem similar, but they are not.
With fireEvent.change you dispatch a change event. Simple and fast.
With userEvent.type you simulate a user clicking on an element and pressing keys on the keyboard. A lot happens and this might lead to a change event, but it probably doesn't.

By using user-event you trade performance for accuracy. You remove the risk that assumptions in your test - e.g. that a change event will be dispatched - might be wrong and something else might break your component. (See the blog post linked above on how easy it is to be wrong about such a basic assumption.)
You remove the need for manual labor - double-checking your assumptions and thinking through possible scenarios of bugs being introduced - by automatically and implicitly testing the whole workflow that happens in production when a seemingly simple thing like typing into a textbox is performed.

(2) Are there any scenarios where it is considered "sufficient" to use fireEvent.change?

Of course, just like there are scenarios where it is considered sufficient to not write any tests at all.
What is the cost of testing?
What is the cost of the system under test failing?
How likely is it going to fail?

If you have a complex project ("particularly large app"), I probably would tend to optimize the CI (e.g. not always running the full test suite) instead of trying to optimize tests (i.e. dispatching a concrete event instead of simulating the user workflow).

(1) Any particular patterns to look for that might explain what, in our code, is causing the performance issue with userEvent.type?

a. It might be that some code in the component under test is slow. E.g. some keyboard event handler that is triggered along the way.

b. It might be that some API in the test environment (e.g. on the DOM implementation) is slow. E.g. we check for pointer-events CSS rule before dispatching pointer events on an element. While this is no issue when testing in browser, this check it known to be notoriously slow in Jsdom.

c. It might be that your performance measurement is misleading and the test itself isn't slow at all. If you just compare two timestamps this doesn't necessarily tell you the time spent executing this particular piece of code.
When we await promises, we allow other code to run in between. If you e.g. use a popular JS test runner like Jest your test runner might just be executing something else which, with synchronous test code, would be executed after your measurement.
Your test runner itself might not execute statements for some period. If you e.g. have more test runner (or other) threads than your system can execute parallelly, it might just be that the test runner is not allocated enough CPU resources.

[joeattardi]

Thank you for the very thorough explanation. I have a better understanding of the differences now. It's probably worth doing some performance investigation into the form component using debug/devtools.

Appreciate the information!