[internal] Support @mui/material@6 peer dependency

[cherniavskii]

Fixes #14055.
Fixes #14369.

TODO:

• Automate @mui/material version check
• Test a package install with @mui/material@next
• Test all the changes with @mui/material@5
• Create a script that will set @mui/material version to next
• Add test_types job to material-ui-v6 workflow
• Make the material-ui-v6 workflow pass
• Schedule material-ui-v6 workflow?
• Use Argos for material-ui-v6 workflow? Is it possible to have 2 Argos checks on the PR?
  Edit: the default workflow sends screenshots to Argos. The material-ui-v6 workflow also sends screenshots to Argos effectively overriding the ones from the default workflow. I think it's OK.

[mui-bot]

Deploy preview: https://deploy-preview-14142--material-ui-x.netlify.app/

Generated by 🚫 dangerJS against e64adb1

[cherniavskii]

This is to make sure that tests are actually using @mui/material@^6:

[cherniavskii]

The dev dependency here is the key to running the tests against the specific version of @mui/material.

[LukasTy]

LGTM. 👍
Thank you for all the effort into this. 👍

I think that we can tackle the material-ui-v6 testing pipeline "scheduling" separately and if we see a need for it. 🤔

[oliviertassinari]

This looks off the direction set in: mui/mui-public#173

Suggested change

	const { user } = render(
	const render(

[romgrk]

The user from render comes from userEvent.setup(), we should probably validate if there's something important done in that setup call:

https://github.com/mui/material-ui/blob/eea5079a00bedb68e27f22b7f94d9a71cc97ee1e/packages-internal/test-utils/src/createRenderer.tsx#L304

[Janpot]

@oliviertassinari @testing-library/react doesn't have a user export. They advise to initialize a new instance for every test which is what we do in our render method wrapper.

Personally, I find overly abstracting things in tests leads to harder to maintain code. Wrappers tend to want to grow indefinitely as the project progresses. But since in core the wrapper was there and used everywhere, it guess it made sense to fold the userEvent code into it. For tests I believe the DRY principle sometimes is harmful. People end up writing a bunch of abstractions over their testing code and they end up becoming just as hard to refactor as the main code.

[cherniavskii]

we should probably validate if there's something important done in that setup call:

If necessary, you can chain multiple setup calls with different options, see https://github.com/mui/mui-x/pull/14142/files#diff-c307c02f110006557e5c75d52b6f6eef030b543ba4b193c936cce9909902f930R113-R115

[Janpot]

Note that, while directly invoking APIs such as userEvent.click() (which will trigger setup internally) is still supported in v14, this option exists to ease the migration from v13 to v14, and for simple tests. We recommend using the methods on the instances returned by userEvent.setup().

The way I understand it is that the instance holds some state around the "user session". i.e. It makes sense to share a single instance per test to maintain that state between calls. But to create a new instance per test to reset the state across different tests, and perhaps also to avoid interference between parallel tests?

[DiegoAndai]

We should open a new issue to discuss improving the current user setup. It is out of topic here.

[oliviertassinari]

we should probably validate if there's something important done in that setup call:

@romgrk Setup doesn't seem to do a lot https://github.com/testing-library/user-event/blob/d0362796a33c2d39713998f82ae309020c37b385/src/setup/setup.ts#L82. I was worried about the performance slowness of running in each test, but it doesn't seem that bad. Not speeding the CI though 😄.

They advise to initialize a new instance for every test which is what we do in our render method wrapper.

@Janpot In the why they advice against it, they seems to point against using beforeEach, but it's not what we would do here?

We should open a new issue to discuss improving the current user setup. It is out of topic here.

I think we can use mui/mui-public#173 for this.

[Janpot]

We recommend invoking userEvent.setup() before the component is rendered. This can be done in the test itself, or by using a setup function. We discourage rendering or using any userEvent functions outside of the test itself - e.g. in a before/after hook - for reasons described in "Avoid Nesting When You're Testing".

afaiu, what we do falls under "by using a setup function".