Lazy user event setup call

[bpinto]

To avoid calling userEvent.setup() unnecessarily on tests that do not have user interaction, I'm considering the following approach but I'm not sure if setup() here would be invoked too late or not. Does anyone know the answer? Thanks.

const customRender = (ui, options) => ({
  get user() {
    return userEvent.setup()
  },
  render: reactTestingLibrary.render(ui, options)
})

module.exports = {
  ...reactTestingLibrary,
  render: customRender
}

Usage:

// userEvent.setup() invoked
const { user } = render(<.../>)

// userEvent.setup() NOT invoked
render(<.../>)

[ph-fritsche]

We recommend invoking userEvent.setup() before the component is rendered.

You could add user on a different function. E.g. in our own tests we have a render function without user and a setup function that adds user.

But if it's for avoiding an unnecessary invocation, it's probably not worth the extra choice for the test author.

[bpinto]

I have seen this solution where different functions are returned and we are using that approach when dealing with other situations, e.g. when we need to wrap the render in a router provider or another type of context provider.

But we frequently use userEvent on our tests and it's a bit of a shame that we need to change the render function when that happens, that's where the lazy invocation idea came from as that would be transparent to the test author.

As I understand, the reactTestingLibrary.render(ui, options) is called before the user() get is called with the implementation above, I just don't know if the userEvent.setup() function is called too late or not. Do you know where do I need to add a dirty console to the user event library to confirm if the setup is happening at the right time or too late?

[ph-fritsche]

We recommend to invoke userEvent.setup() before invoking .render() of the framework libraries so that the DOM is prepared the same way for all tests. This is the case in our example of a setup() function.

In almost all cases it won't make a difference, but it could make for a nasty bug if you hit one of the rare edge cases.
Even more so since most test environments reuse the document for tests in the same test suite. Therefore subsequent tests work with the document already prepared by userEvent.setup() in previous tests.
Should such subsequent test rely on that preparation, refactoring previous tests can trigger a bug in that test which might be hard to track down.

The execution time of userEvent.setup() is negligible and it is safe to invoke it multiple times on the same document.

Imho trying to optimize calls to userEvent.setup() looks more like inventing a problem than solving one.