Running eight component tests for a complicated form in a *real browser* (!) in 768ms? This changes my stance on mainly using a mock DOM environment for testing!
@vitest.dev Browser Mode is a true paradigm shift!
@vitest.dev Browser Mode is a true paradigm shift!
Comments
CI will most likely be slower, true!
With vitest/jsdom I usually do “full tests” where I navigate to a page, render the whole app and I interact with the ui.
Last time I’ve tried with vitest/browser I struggled to navigate to an url 🥲
subsecond iteration loop is great value for development, but would be incredible if that carries over to CI too
One caveat though: this video was recorded on an M3 Max machine. So CI runs will likely be slower. At least on your average GitHub Actions type of services.
But Vitest Browsr Mode / Playwright do help you were they can e.g. awaiting locators. Everything else e.g. having no race conditions in your code, stable mocking / stubbing of network requests is on you. Regardless of tools.
and just run CI on a fleet of M3 Maxes, problem solved 😎
But an impressive as this is it is very much optimized for the particular Preact use case. When testing an app or components, many of the assumptions made in the case of Preact are not true.
The Preact suite, which that talks about, is made up of _unit tests_, which should be done in the browser. Jsdom is a slow, somewhat accurate representation of the browser and is the main thing you should drop.