dom-testing-library: Performance issue with the byRole query causing timeout errors

@kentcdodds any updates on this? We are still hitting this 3 years later with @testing-library/dom v8.11.3 and @testing-library/jest-dom v5.16.5.

However, I did see there is a v6 for jest-dom. But not sure if that addresses this issue.

I totally agree with @eps1lon , but if there is something to do to improve performance we should give it a try, shouldn’t we? The difference between getByRole and getByLabelText is pretty big (notice in the test I compared to 5 times the duration and it’s still longer than that), so I think we should at least make some effort to reduce it

If you’re confident that you can manually verify the checks ByRole provides then I suggest switching to other queries. ByRole considers the a11y tree, styles and the accname spec. These checks are expensive but have a higher confidence that what you’re testing is actually what a screen reader would “see”.

It’s like any other tool: If you don’t need the features then you should switch to a tool with smaller feature set. If test performance is a bigger issue for you than test confidence then ByRole is not the right tool.

One thing: A real-world repro would help us a lot improving performance. We’ve had success in the past with good repros since they help us identify bottlenecks. Screenshots of code don’t help us very much. Small examples that don’t reproduce the issue are also not helpful.

I’ve made a contrived repo here: https://github.com/jihchi/698_byrole_performance_issue

there is a 3rd-party datetime picker and it would take ~1 second when you opened the calendar and pick a specific date in the calendar by using getByRole('button', { name }).

I also experience this problem but only on my CI runners, not on my local machine.

I understand that byRole might take more time but then I would prefer a global setting to increase the default timeout of the findBy -queries, otherwise I have to litter all my tests with , {timeout: 2000}

I believe that the accessibility checks are nice, but in some cases you don’t need them- take for example a UI framework. That’s one of the times where you absolutely do want these checks. But then say you have an application that uses the framework- if the only thing that needs to verified is application behavior, and speed is absolutely important for development.

I think it very much depends on your needs. Not to mention some people have separate pipelines for these checks (eg. lighthouse)

Shouldn’t this issue be moved to @testing-library/dom?

I have the same problem.

@alexkrolick I doubt it. Based on the research I did, it looks like our major bottleneck is getComputedStyles from JSDOM and querySelectorAll… These are known to be much slower in JSDOM rather than the browser. Also, their implementation is quite different from what I saw last time I checked.

As promise serious testing materials https://github.com/HugoPoi/bug-perf-demo-getByRole/tree/main

@idanen For sure, I would definitely love to see any improvements of ByRole API!

According to my investigation, @eps1lon has summarized the causes pretty clear and I agree with him:

If you’re confident that you can manually verify the checks ByRole provides then I suggest switching to other queries. ByRole considers the a11y tree, styles and the accname spec. These checks are expensive but have a higher confidence that what you’re testing is actually what a screen reader would “see”.

It’s like any other tool: If you don’t need the features then you should switch to a tool with smaller feature set. If test performance is a bigger issue for you than test confidence then ByRole is not the right tool.

Simply say, you may encounter slowness of ByRole API and/or eventually a timeout occurs when you have a large amount of DOM elements.