Mock window.assign.location and window.open in browser mode

[thomasneger]

Hi vitest community!

In our system, we have lots of window.location.assign and window.open throughout the code base that we unfortunately have to use to sometimes navigate programmatically to legacy parts of our apps.

We migrated to latest vitest browser mode and have been loving it. But we had to drop all previous happy-dom tests that were mocking vi.spyOn(location, 'assign') which does not work in a real browser.

Hopefully not too many people have to write tests like us. We have a found a few workarounds, but nothing feels truly "vitest".

Happy testing :)

[krotname]

In Browser Mode I would treat window.location.assign as effectively not mockable in the old happy-dom style. Browser Mode is running in a real browser, so Location behaves like the platform object it is; vi.spyOn(location, "assign") working in DOM simulators was the less-realistic part.

For window.open, you may be able to stub/spy depending on the browser/property descriptor, but I would not build a test strategy around patching browser navigation globals.

The most Vitest-friendly pattern is to put navigation behind your own module boundary and mock/spy that module instead:

// navigation.ts
export function assign(url: string | URL) {
  window.location.assign(url)
}

export function open(url: string | URL, target = "_blank", features?: string) {
  return window.open(url, target, features)
}

Then in Browser Mode:

import * as navigation from "./navigation"

vi.mock(import("./navigation"), { spy: true })

vi.mocked(navigation.assign).mockImplementation(() => {})
vi.mocked(navigation.open).mockImplementation(() => null)

That lines up with the Browser Mode limitation documented for module exports: native ESM namespace objects/browser globals cannot always be reconfigured like they can in Node/jsdom, so Vitest supports { spy: true } module mocking as the escape hatch.

For tests where you want real navigation semantics, I would move those to Playwright/Cypress-style e2e and assert the URL/popup behavior there. For component/unit tests, the wrapper module is the least surprising long-term approach.

[thomasneger]

Thank you kindly for the write up.

At first, I was reticent to introduce wrapper functions around common browser features, as I always found it annoying to work in projects where I couldn't reach for the raw API directly. For context, I help maintain a decently sized monorepo, with multiple teams, so we always think a lot before introducing extra concepts in.

However, I'll admit that I really like the way you split it into two functions that are 1-1 copies of the originals. There's not much overhead here, which I really like.

This is actually starting to grow on me:

import { assign, open } from '@/navigation';

I'll take this with the teams. This seems to me like it's our happy path.

Have a wonderful day.