[code-infra] Split date-picker test files

[JCQuintas]

These are improvements made during the vitest PR

I'm moving the changes out so that PR is leaner.

• Split describes.**.test.tsx from x-date-pickers* packages into smaller, faster files.
  • The main issue is that these files had a lot of tests to run, which made them extremely slow, where some files could take up to 50s to finish.
  • divided into:
    • describeConformance.*
    • describeValue.*
    • describeValidation.*
  • Some exceptions like describeValueMultiInput.DesktopDateRangePicker.test.tsx and describeValueSingleInput.DesktopDateRangePicker.test.tsx had to be split into even smaller files.
• Smaller changes like removing unnecessary clock in describeConformance tests

Ofc, suggestions on how to name the files are welcome, I went with the function names to be easier to understand. :)

[mui-bot]

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

Generated by 🚫 dangerJS against e8ed4f7

[flaviendelangle]

Could you describe why splitting those files improve the tests?
Is it because we run more tests in parallel and those files contain so many tests that they end up being a bottleneck?

[JCQuintas]

Could you describe why splitting those files improve the tests? Is it because we run more tests in parallel and those files contain so many tests that they end up being a bottleneck?

One of the main issues with vitest we have in CI is that it gets "stuck" at some steps. It was caused by both OOM or CPU-bottlenecks.

While disabling file parallelisation in CI solves most of the issues, the date-pickers package would still get stuck in the same couple files from time to time.

Mostly:

• describes.DesktopDateTimeRangePicker.test.tsx
• describes.MobileDateTimePicker.test.tsx
• describes.DesktopDateTimePicker.test.tsx
• describes.DesktopDateTimeRangePicker.test.tsx
• describes.MobileDateRangePicker.test.tsx

And probably more.

I could have fixed those files specifically, but decided to implement a more systematic approach so it is harder for it to happen in the future.

[flaviendelangle]

OK
If it improves CI reliability, I'm all in favor of doing the split.
In term of pure DX, I don't think the split helps, but it's not the main argument here clearly 👍

[JCQuintas]

OK If it improves CI reliability, I'm all in favor of doing the split. In term of pure DX, I don't think the split helps, but it's not the main argument here clearly 👍

Indeed, I went with a filename matches function pattern to be clearer. Since when replicating these tests in the future you can leverage what is already there. (read: copy/paste) And replace what is useful for you.

In the end these test files were just running other functions, which themselves run a lot of other functions/files, so most meaningful interactions would be in different files anyways.

It is not as simple as before, but it should be quite simple to replicate in the future 😅