[internal] Migrate test runner to vitest

[brijeshb42]

Note that the class names for the generated css have changed because earlier, the root directory was considered from repo root, but now, it considers the package directory as the root. And classname generation depends on this path.

• I have followed (at least) the PR section of the contributing guide.

[oliviertassinari]

What's the motivation for this change?

[Janpot]

For historic reasons Toolpad ended up using vitest instead of mocha for its unit tests. Current Toolpad could benefit from some of the test infra of core and maybe we'll try again to switch, but I have to admit, it's a lot less painful compared to karma+babel+mocha. Can't explain the the motivation for this change, but I can share my experience with vitest:

pros:

• faster and parallel
• no need for babel, runs typescript/jsx code out-of-the-box
• actually handles module resolution correctly as expected
• built-in mocking (looking at you Datepickers for testing multiple versions of date-fns)
• no need for karma to run tests in the browser
• it just works

cons:

• can't reuse mui test utils
• no babel means potentially testing differently compiled code.

[oliviertassinari]

How do we run the tests in a real browser with vitest? As I understand things:

• The reason we use mocha is so we can run tests in a browser with Karma.
• We can't use playwright because it's x10 slower than Karma, and Karma already needs to be x2 faster to have a good PR DX.
• We can't use jsdom only because it's not accurate enough, at least anytime we go out of the standard React rendering flows, e.g. data grid, I believe @romgrk experience was too limited.

Now https://github.com/emotion-js/emotion/, https://github.com/callstack/linaria/, https://github.com/styled-components/styled-components/, seem to run tests with jest (and maybe jsdom) only.

https://vitest.dev/guide/browser.html + https://vitest.dev/guide/improving-performance.html, oh maybe could solve two pain points 🤔

cons: no babel means potentially testing differently compiled code.

We should transpile the source to be close to production, but I guess this won't be an issue.

const: can't reuse mui test utils

We should be able to reproduce equivalent utils.

[Janpot]

How do we run the tests in a real browser with vitest?

Yep, they're adding a browser mode. Granted, it's not declared stable yet, but I made it work today in Toolpad in relatively short time. It was that or move to mocha+karma. I gave it a quick shot, and it's quite delightful, still not supporting the full functionality of the node.js runner, but certainly seems to be usable for us.

We should transpile the source to be close to production, but I guess this won't be an issue.

vitest transpiles the code for you, with vite. It's a trade-off I'm personally willing to make. I think it could make sense to try and cover this use-case with a few integration tests instead. Fewer tests, but closer to actual production code.

[JCQuintas]

We should transpile the source to be close to production, but I guess this won't be an issue.

Would moving to vite instead of babel be a huge issue? We have some complex babel transpiling in X that I'm not sure would be portable to vite.

[Janpot]

We have some complex babel transpiling in X that I'm not sure would be portable to vite.

Which transformations do you think aren't portable? The one I'm aware of is the macro in MUI core for error messages. I don't think X is even making use of that? In any case, I don't think there is anything preventing us from using a babel transform in vite if necessary. But I'd love to get rid of the macro system altogether if we can, making our code portable to other compilers would be a big win.

IMO transforming the test format from mocha+chai to vitest will probably be the most intensive part of the process.

[JCQuintas]

Oh, I was mostly asking if there are known issues, I don't have a lot of exp with vite/vitest. But I would guess on X the date adapters import replacement could be an issue.

[Janpot]

But I would guess on X the date adapters import replacement could be an issue.

😄 Actually mentioning this exact use-case in my comment above.

• built-in mocking (looking at you Datepickers for testing multiple versions of date-fns)

I expect that we can build that on top of vitest module mocking. I'm not a huge fan of this method as it's quite a lot of magic, but it should be much more straightforward to do from DX point of view. 🤷 As long as we're not starting to overuse this feature everywhere.