new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Vitest · Guide · all subjects

browser/limitations

7 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Thread blocking dialogs limitation

Thread blocking dialogs like 'alert', 'confirm', and 'print' cannot be used natively in browser mode because they block the web page, preventing Vitest from communicating with it. Vitest provides default mocks for these APIs to prevent execution hangs. It is recommended to manually mock these web APIs for a better testing experience.

Module export spying limitation in browser mode

In browser mode, the module namespace object is sealed and cannot be reconfigured like in Node.js tests. This means 'vi.spyOn' cannot be called on an imported object because it will throw an error.

Browser mode is not a drop-in replacement for standalone end-to-end test runners

Vitest browser mode does not completely replace standalone end-to-end test runners. Users should augment their Vitest browser experience with a standalone browser-side test runner like WebdriverIO, Cypress, or Playwright.

Browser mode requires longer initialization time

Vitest browser requires spinning up the provider and the browser during the initialization process, which can result in longer initialization times compared to other testing patterns.

Interaction state persists between tests with playwright and webdriverio providers

With playwright and webdriverio providers, interaction state like pressed keys or pointer position and hover state can persist between tests in the same file. Vitest resets unreleased keyboard state automatically before each test, but pointer position and hover state are not reset automatically since resetting pointer position can be expensive. To reset hover state explicitly, use await userEvent.unhover(document.body) in beforeEach.

Common limitation: listbox not supported in selectOptions

Unlike @testing-library, Vitest does not support listbox at the moment in userEvent.selectOptions, though support is planned for the future.

dragAndDrop not supported by preview provider

userEvent.dragAndDrop API is not supported by the default preview provider.

Give your agent this brain