Skip to content

Add browser coverage for human-readable routes - #252

Open
snowyukitty wants to merge 7 commits into
cdnjs:masterfrom
snowyukitty:test/human-output-browser
Open

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

Conversation

@snowyukitty

@snowyukitty snowyukitty commented Jul 29, 2026

Copy link
Copy Markdown

Type of Change

  • Utilities: Normalize Vite module IDs while resolving island entry points.
  • Tests: Add route-adjacent Vitest Browser/Playwright coverage for the human-readable API and library-version routes.
  • 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 Worker through Cloudflare's createTestHarness() lifecycle and a same-origin Vite proxy.
  • Assert the /api documentation and /libraries/backbone.js/1.1.0 version page when WEBSITE_BASE identifies the website origin.
  • Exercise the hydrated Files island by selecting the displayed Source Maps filter and checking the resulting file links.
  • Keep browser coverage beside the corresponding route specs and allocate loopback 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/

Comment thread src/routes/human.browser.spec.ts Outdated

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?

@snowyukitty

Copy link
Copy Markdown
Author

Addressed both suggestions: the browser suite now uses createTestHarness(), and the assertions live in route-adjacent api.browser.spec.ts and library.browser.spec.ts files. I also incorporated current master (through #261) and kept the browser setup aligned with the WEBSITE_BASE route contract.

Fresh current-base checks pass: Chromium 2/2 twice, unit tests 485/485, types, lint, focused formatting, a Wrangler dry run, and git diff --check. Thanks!

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