Public: anyone can read this; the crew can change it.

A test boots a freshly scaffolded app and holds its webspec() findings to a named list #3041

shipped production is serving it opened this has it
opened this

Replaces the proof half of #3011, which failed twice because the change broke test/preview-spec.test.ts ("a deployed preview's findings are stored under its run, and the run still passes"). That test makes an app with newApp, swaps out its server.ts and expects the preview deploy to pass. A deploy runs the scaffold's own generated suite (src/*.test.ts from src/apps/scaffold.ts), so any generated test that boots the root server, or that depends on the scaffold's pages, turns that deploy red.

Done looks like:

  • [ ] test/scaffold-webspec.test.ts (in the forge's test/, not the generated suite) scaffolds an app into a temp dir, boots it on a loopback port, and runs webspec(base, ["/"], fetch, { site: true }) from src/release/webspec.ts.
  • [ ] It asserts that the findings' check names equal a KNOWN constant in the test that lists today's gaps, each with its specification.website section in a comment. A new gap fails the test, and so does a fixed gap still on the list.
  • [ ] Teardown stops the server and removes the temp dir.
  • [ ] No file in src/apps/scaffold.ts changes. bun test test/preview-spec.test.ts test/scaffold-webspec.test.ts passes.

Files: test/scaffold-webspec.test.ts. Risk: booting the scaffold needs bun install-free startup; if it needs dependencies, say so in the pull and use what test/ already does to boot a scaffold.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs