Sample-site Markdown test catalog#
34 standalone browser tests; ten optional section files. The deepest test is four folders below the catalog root.
Catalog root: sample-site/. Tests use .snag.md; optional section.md supplies guidance, and other Markdown is ignored.
Run and inspect#
From the SnagBadger checkout, install the pinned toolchain and dependencies, then build the workspace. Start the maintained site with pnpm dev:examples; use its printed URL as <sample-base>. Keep the server and outputs owned by that worktree. For deployment, <sample-base> includes the repository prefix.
node tooling/testing/plan.mts inspect --catalog examples/test-plans/sample-site
To execute, use the run-test-plan skill with this catalog and the agreed base URL. Configure your installed browser MCP for genuinely new contexts and a fresh delegated worker per test. See the runtime contract. The standalone CLI needs its bridge requests serviced by that coordinator; it is not unattended browser automation.
node tooling/testing/plan.mts start --catalog examples/test-plans/sample-site --output test-results/sample-run-UNIQUE --runtime <your-runtime.json> --tag smoke
<sample-base> is prose shorthand supplied to the coordinator, not runner variable interpolation. Most checks use the developer controls: use pnpm dev:examples, not a production build that intentionally hides those controls. A usable existing server may also be supplied.
Reading the hierarchy#
- Root
section.md: browser executor, acceptance level, screenshot requirement, optional video, sample Jira destination, server preflight and per-test cleanup. - Profile persistence has deeper fixed/buggy sections, selecting the mode in a per-test instruction hook. No authentication exists on this sample site; see function-hook configuration for an actual authenticateUser integration.
profile/form,profile/navigation,plain-html/interaction, and several deep theme/recorder directories have no section file: directories still create report groups and inherit their ancestors.- Plain HTML and branding explicitly disable the root navigation hook before supplying their own. The navigation test overrides inherited cleanup. Setup runs root to leaf; cleanup reverses it.
- Branding replaces the inherited destination with Jira
SAMPLE-BRANDING. Both project keys are illustrative: replace them for your project, and never submit the demo findings automatically. - Smoke is assigned selectively to individual tests, not the root: saying “execute smoke test plan” excludes known failures and most extended checks.
sample-site,mobile,keyboard,privacyand other tags demonstrate inherited and local filtering. - Recorder tests override optional video with required video; unavailable proof yields incomplete. Mobile and system-appearance tests require actual viewport/device capabilities; missing action capabilities should be reported blocked.
Expected failures and evidence#
The two profile/persistence/buggy scenarios carry inherited known-failure tags and should fail the product persistence expectation. The fixture is deliberately broken. There is no expected-failure/x-fail schema field; keep the failed attempt and use its Create bug draft to explore reporting. Fixed mode retains state only within the current page; reload deliberately resets it.
A site demo recording or “illustrative evidence” checkbox is not the runner video. Record real screenshots/video and assertion observations separately. The site’s local simulations do not submit Jira reports or durably save drafts. Each case is independent: it must not consume state produced by the previous case.
The catalog is authored coverage, not a claim that every Markdown scenario was agent-executed. Parser/selection validation and maintained automated browser journeys verify the examples and sample behaviors; execution produces a separate report.
Inventory#
| Study directions wrap and preserve shareable URLs | branding, navigation |
Copying to your project#
Copy the catalog directory and retain only behaviors your application has. Replace paths, fixture setup, expected outcomes and illustrative project destinations; change stable IDs when you introduce distinct tests. Frontmatter uses only the existing schema: optional section-local ID/title/tags here; executor, components, levels, instructions, destination, evidence and hooks inherit from sections. The full contract documents replacement and function hooks. Supporting Markdown may live inside the catalog. Prefix filenames for start order; numeric order has no precedence.