Repository navigation
Add browser testing for human output #188
Description
With #173 + #187 now in place, it makes sense to begin properly testing the content of the human output like we do for the regular API responses.
We should use Vitest's built-in browser support (Playwright-based) to do this: https://vitest.dev/guide/browser/
Activity
m13v commentedon Apr 6, 2026
vitest browser mode with playwright is a solid choice for testing rendered HTML output. one thing we ran into: the default vitest browser setup doesn't wait for fonts to load, so if your human output includes any custom typography the screenshots or assertions can be flaky depending on font loading timing.
also worth considering that vitest browser mode runs tests in a real browser context but the test isolation model is different from a standard playwright test. each test file gets its own browser context by default but if you need to test navigation or multi-page flows you'll need to configure that explicitly. for testing static HTML output content though, the default setup should work well since you're mostly asserting on DOM content and layout.
MattIPv4 commentedon Apr 6, 2026
👍 We have no custom fonts, we rely on the system font stack. I also can't imagine we'd be doing any tests that would be reliant on fonts loading, I'd just be looking to assert that key elements are in the DOM and accessible to the user.
And yes, I can't imagine the default isolation model will give us any issues, as again, this is just going to be testing the DOM output of given routes to confirm key elements are present.