[docs] Update testing guide

[eps1lon]

• Recommend DOM testing (linking to testing-library intro)
  There's not much we can add here since none of the examples would be Material-UI specific.
  App tests focus more on high level stuff on which we can't advise much. Just don't rely on internals.
• move "Internal" section to document end
  It's probably the least important part of that page.
• remove API docs for /core/test-utils (follow-up on [core] Remove /test-utils #21855)
• Add removal of /core/test-utils to migration guide

Closes #17070

[mui-pr-bot]

Details of bundle changes

Generated by 🚫 dangerJS against 07a8acf

[oliviertassinari]

Regarding the migration, I wonder if we should add a depreciation warning on v4. Covering it in https://next.material-ui.com/guides/migration-v4/ will help.

[mbrookes]

I wonder if this sentence should come at the end of the section, after the approach has been fully explained? The prior sentences only allude to what not to do...

[eps1lon]

That makes more sense 👍 I moved it after the example.

[eps1lon]

I wonder if we should add a depreciation warning on v4

Yes. This is what I've been trying to explain. We can do breaking changes first and then later (and separately) work on deprecations.

[oliviertassinari]

Yes. This is what I've been trying to explain. We can do breaking changes first and then later (and separately) work on deprecations.

Agree, so:

• If there is no migration path, it's probaby better to break stuff on v5 (to test the changes first). After and if it's possible, add a deprecation on v4. It's our case here.
• If there is a migration path, it's probably better to start from v4 (where there are the most constraints), then cherry-pick the commit without the migration code (only the code required) on v5. We have tried to do the opposite with @mnajdova on the Accordion (v5 then v4), we came to the conclusion that it wasn't an optimal order.

[eps1lon]

I don't know how else to explain. I make every breaking change on next without any thought about deprecation. I think about these completely separate to have maximum freedom for v5.

[oliviertassinari]

@eps1lon I don't have any strong points of view on this, your approach is worth pushing further. My previous comment was meant to share what seems/could to be easier for us (I'm not saying it is). But I'm wondering if spending time on helping v4 to v5 migration outside of the markdown migration guide has a positive ROI in the first place. I guess we will get feedback, and act based on it. So v5 first, then v4 -> v5 as/if we get feedback, sounds like a possible great strategy.

[mbrookes]

@oliviertassinari The complication with @mnajdova's PR was simply that we started to do it one way, then switched to doing it another.

So v5 first, then v4 -> v5 as/if we get feedback, sounds like a possible great strategy.

Not "as we get feedback", it's just a separate task. (Unless you're suggesting that we don't provide deprecation warnings by default?)

[oliviertassinari]

Not "as we get feedback", it's just a separate task. (Unless you're suggesting that we don't provide deprecation warnings by default?)

I'm secretly hoping that we can get away without these deprecation messages. But yeah, I doubt it, so "separate task" sounds great.