I really wish. Almost 1 second for 8 tests is still pretty slow though. That would make our 3000 tests take over 5 minutes, vs the 30 seconds they take now. But I could see having a separate smaller suite for some smoke tests.
Comments
Log in with your Bluesky account to leave a comment
I’m not sure what they’re measuring here, but from the video it looked like the 700ms was just for the tests themselves and the startup cost was on top of that.
That is certainly something to think about, but one argument convinces me more than any other: how many users are using your apps using JSDOM? Ultimately, we're testing to provide a good experience for the *users*. Users use browsers.
I think browser based testing could be particularly useful in projects like React Aria Components. Especially if it runs on multiple browsers, and multiple browser versions!
Yeah I agree. We’ve been wanting to do that for years but it’s just too slow for the number of tests we have. That’s why I say maybe we could have a separate smaller suite of smoke tests.
Yeah sharding playwright component tests has done wonders for us, definitely a good suggestion. I haven’t looked much into the Vitest browser integration, but from what I can see it’s using playwright as the runner correct?
Give it a try instead! Here I have ~160 tests running faster in browser mode than in JSDOM, ~320ms vs ~500ms. I'm testing my utility library against real browsers and JSOM with Vitest's workspaces.
As far as I know, we still haven't solved parallelism yet in vitest or web-test-runner. That would be the key to making this fast beyond simple suites I think
The chrome throttling hit us hard 😅
vitest apparently does similar now too (multiple tabs, an iframe per tab for sandboxing of some sort)
so it'll suffer from the same things
I did think about making some kind of browser pool library to solve this that both could use, but lost track of where I got to with it 😅
Yep I did a lot of investigation into it too for both wtr and vitest. iirc, same origin often shares a thread, but also Chrome heavily throttles background tabs anyway. The true solution imo is that chrome has a way to turn off background throttling at least in ci
Comments
And of course perf isn't the only important thing. I look forward to being able to test layout computation related stuff at a component level.
The chrome throttling hit us hard 😅
https://x.com/asleMammadam/status/1648146137214246912
maybe the @vitest.dev can do test splits with browser tabs?
https://x.com/asleMammadam/status/1647849433671802881
so it'll suffer from the same things
I did think about making some kind of browser pool library to solve this that both could use, but lost track of where I got to with it 😅