migrate unit tests from karma to vitest

[k-yle]

this is blocked by #10431, and needs to be rebased after that PR is merged

---

Closes #10408, Closes #9805, Closes #10382

This PR migrates all our unit tests from karma to vitest. See issue #10408 for more details about why this beneficial. In short: the development cycle is now 10-20x faster, which makes it significantly easier and more pleasant to write tests.

This was suprisingly easy, and only a few test files had to be modified - these changes have been split into a separate commit.

[k-yle]

I've left some code review comments explaining why certain test cases had to be changed

[tyrasd]

#10431 is merged now. There are no merge conflicts, but can you please double-check that everything works as expected?

[k-yle]

thanks @tyrasd :) it looks like github automatically changed the target branch which is a neat feature. I've rebased it anyway so that the history is cleaner, and I can confirm that it still works

[tyrasd]

Perfect. 💯

Only one comment: I noticed that on my system, a full run of the new test suite is significantly slower then previously:

Duration 158.62s (transform 3.53s, setup 204.50s, collect 5.84s, tests 9.83s, environment 63.09s, prepare 13.09s)

For comparison, the old code runs npm test:spec in approximately a minute here.

Also the CI on github seems to be a bit slower now: new: 1m 51s, old 1m 8s. 🤔

Is that expected because of jsdom overhead?

[k-yle]

Only one comment: I noticed that on my system, a full run of the new test suite is significantly slower then previously: [...]

interesting, I hadn't checked the overall execution time since it felt similar, but it is indeed slower :(

For me, the more important metric is the time between saving a file, and seeing the test results. That's now reduced to 0-1 seconds, previously it was 10-20 seconds or longer. (since we don't need to run npm run build after every change, and there is a 'watch' mode)

But it's a shame that this is a trade-off... We could try to use the --no-isolate flag, but this will require tweaking a few more tests. In GitHub Actions, it only takes 75 seconds with --no-isolate!

[tyrasd]

For me, the more important metric is the time between saving a file, and seeing the test results.

Agree. 👍

We could try to use the --no-isolate flag

Didn't the test previously essentially run in something equivalent to that? 😉

Also, as the iD modules should not interfere with each other via global states anyway, it might be even preferred to run them like this?!

I just found out that running it with --no-isolate --maxConcurrency 1 seems to work. Without limiting it to a single thread, there are odd errors like ReferenceError: window is not defined, which I don't immediately see where they might originate from. 🤷 But as it's also a lot faster than the isolated approach, it might be worth considering…

//edit: turns out this was unfortunately just a fluke. It now also fails for me even with --maxConcurrency 1. Strange.

[k-yle]

I figured out what was causing the flaky tests and enabled --no-isolate in 156f6a8, which has slightly sped up the process