How to pass in the window & document context into Preact for testing with JSDOM?

[alshdavid]

I'm trying to use happy-dom to test my preact application and it gets window and document from globalThis

Is there a way to inject the window or document I want Preact to use for rendering?

import { h, render } from 'preact'

const testWindow = new JSDOM()

// This looks for "globalThis.document"
render(
  <div>Hello World</div>,
  testWindow.querySelector('body'),
)

I'd like to be able to specify the document instance

renderInto(
  <div>Hello World</div>,
  testWindow.querySelector('body'),
  testWindow.window, // Use this window rather than globalThis.window
)

[marvinhagemeister]

Does setting the global work?

globalThis.window = testWindow.window

[marvinhagemeister]

Which test runner are you using? If you're using any of the popular test runners (jest, vitest, mocha, ava), then those parallelize test files by running each file in its own process, but still run all tests inside a file in series. The only test runner that I'm aware of that does it differently is the one from playwright, but if you're using playwright then you'd do proper e2e testing anyway.

[rschristian]

Not to get into too much of an X/Y problem situation, but I think we'd generally recommend against rendering directly into document.body anyhow -- it's ideal if Preact renders into a node it can fully own.

For a test suite, this means you can create a container per-test to render into, simply removing the container once the test is done. Depending on your specific needs, this can be a great mix of isolation & performance.

[marvinhagemeister]

^To add to this: We do the same thing for testing Preact itself.

[alshdavid]

Oh yeah, that's fair. I was just being lazy in the example, I normally don't use document.body, it's was just easier to type out for the example compared to making a tag and querySelector haha.

[alshdavid]

Which test runner are you using?

I'm using the built-in nodejs test runner and happy-dom (philosophically, the less external tooling I use, the longer my project longevity when left unmaintained).

With the native test runner, each file runs in its own worker process and setting the document on globalThis does work as described.

I was experimenting with running each test/it block concurrently in the hope that I would see a further reduction in overall test times.

That said, thinking about it now, assuming I've mocked timers and stubbed async behaviours, there may not actually be a benefit to running the tests concurrently given the renders themselves won't yield to the event loop so I'll be maxing out the thread anyway.

Though I can't validate that, haha