Skip to content

Add browser coverage for human-readable routes - #252

Open
snowyukitty wants to merge 1 commit into
cdnjs:masterfrom
snowyukitty:test/human-output-browser
Open

Add browser coverage for human-readable routes#252
snowyukitty wants to merge 1 commit into
cdnjs:masterfrom
snowyukitty:test/human-output-browser

Conversation

@snowyukitty

Copy link
Copy Markdown

Type of Change

  • Utilities: Normalize Vite module IDs while resolving island entry points.
  • Tests: Add Vitest Browser/Playwright coverage for human-readable API and library-version output.
  • Something else: Install Chromium and run the browser suite in CI.

What issue does this relate to?

Fixes #188

What should this PR do?

  • Run browser tests against a real local Wrangler worker through a same-origin Vite proxy.
  • Assert the /api?output=human documentation and /libraries/backbone.js/1.1.0?output=human version page with accessible roles and labels.
  • Exercise the hydrated Files island by selecting the displayed Source Maps filter and checking the resulting file links.
  • Keep browser specs separate from the Workers test pool and allocate local ports dynamically.
  • Normalize Vite module IDs so island bundling works with Windows paths.

What are the acceptance criteria?

  • npm test
  • npm run test:browser
  • npm run lint
  • npm run types
  • npx wrangler deploy --dry-run

This adds test coverage and cross-platform build normalization; it does not change the rendered UI, so before/after screenshots are not applicable.

@MattIPv4 MattIPv4 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this! Instead of unstable_dev, I wonder if we can use the new createTestHarness designed for use w/ Playwright etc.? https://developers.cloudflare.com/changelog/post/2026-07-21-integration-test-harness/

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of a dedicated spec file for the human outputs, I think it'd be good to include this as part of the existing spec files for each route, if possible? Or, if not, at least have a dedicated browser spec file alongside each existing route/spec?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add browser testing for human output

2 participants