This is a follow-up on the discussion we have started in #1730 (comment) between @eps1lon, @dmtrKovalenko, and @oliviertassinari.

The arguments in favor we have explored so far:

1. It's fast. For comparison: with Cypress, we need ~26s to run 28 tests, with testing-library, ~1s (60s / 1956 tests * 28 tests).
2. It's end-to-end and reliable. Running the tests in JSDOM and a ChromeHeadless is probably what yields 80% of the value but we can also easily run them in BrowserStack.
3. It works well, at scale. The problem is already mostly solved in the main repository, we don't need to complexity the stack with different tools. We can apply back what we have spend months refining, and move to solve more user-facing problems. This is has a significant compounding implication, we can have 1. Material-UI's engineer more easily making contributions between the different parts of the product, 2. any improvements we do to the stack benefits all the components.

The concerns against we have explored so far:

• What about TDD? TDD can be done by watching the source and scoping the tests that run with either .only or a filter.
• What about visual regression tests? I believe it works great in the repository's stack. By not taking screenshots of the pages of the documentation, we don't get false positives when updating the wordings. By using Argos-CI, we need to pay $0/month instead of $800/month to have the infra running. It's also going to be better after [test] Use playwright instead of vrtest material-ui#21449.
• Tests are hard to debug. I believe the usage of these 3 leverages makes debugging easy. 1. Dead simple test cases 2. debug() utils, 3. Assertion playground http://testing-playground.com/. In the event, it's not enough, I copy and paste the test case and run it in the documentation, to see how it behaves. Now, there is definitely a concern around getting used to the tooling, it takes time, which echos back to the value of point 3. and why it's important to share it between all the components.
• JSDOM isn't reliable. We have faced this problem in a couple of cases in the codebase. On the 2,000 existing tests, they are some that need to be skipped. For instance: https://github.com/mui-org/material-ui/blob/d0bfcb4f11fd3904b1e235d80fbfe23758de8372/packages/material-ui/src/Select/Select.test.js#L1018. The solution we have found to this problem is to run the same tests in different targets: JSDOM, ChromeHeadless, Firefox, Safari, Edge.
• Are the tests end-to-end? Yes as much as we can. We could even introduce feat: make several API and implementation improvements testing-library/user-event#348 if necessary.
• We have too many tests to migrate. It seems that we have ~100 tests to migrate, to give a comparison it's about the number of tests the Autocomplete has, it should be manageable.

I believe the conclusion is that we should migrate all the tests to testing-library until we hit a roadblock