Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
sbroenne avatar

Chromium Local Smoke Tests

  • 1 installs
  • 74 repo stars
  • Updated August 4, 2026
  • sbroenne/mcp-windows

Pattern for always-on Chromium browser smoke tests using a deterministic local Edge page plus one stable public web page.

About

Describes a small, honest browser smoke-test slice that proves real page interaction via UI automation. A developer uses it when adding always-on Chromium coverage without creating browser-specific MCP tools.

  • Pairs local Edge static HTML with a stable public page
  • Asserts landmarks, ARIA-labeled inputs, and post-click DOM changes

Chromium Local Smoke Tests by the numbers

  • 1 all-time installs (skills.sh)
  • Ranked #1,750 of 2,153 Testing & QA skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/sbroenne/mcp-windows --skill chromium-local-smoke-tests

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs1
repo stars74
Last updatedAugust 4, 2026
Repositorysbroenne/mcp-windows

What it does

Pattern for always-on Chromium browser smoke tests using a deterministic local Edge page plus one stable public web page.

Files

SKILL.mdMarkdownGitHub ↗

Context

Use this when the team wants a small, always-on Chromium browser slice that proves real page interaction honestly without creating browser-specific MCP tools.

Pattern

  • Prefer Edge + local static HTML for the deterministic slice, then pair it with one stable public-web page for required internet coverage.
  • Keep the scope to page content discovery first: landmarks, ARIA-labeled inputs, and buttons.
  • Launch Edge as an app window with startup hygiene, --force-renderer-accessibility, and an isolated `--user-data-dir` for reliability.
  • Keep the public tier to a stable browser-testing page (for example https://demo.playwright.dev/todomvc/) and assert only long-lived page content such as labeled inputs or links.
  • Keep browser chrome, logins, and ambient profile state out of the default slice.

Good first assertions (local tier)

  • Landmark or navigation container is discoverable.
  • ARIA-labeled search box resolves as Edit.
  • ARIA-labeled primary action resolves as Button.

Good second-slice assertions (local interaction tier)

  • Add one editable field whose value can be typed and read back to prove ui_type + ui_read.
  • Add one always-visible text node to prove baseline ui_read on Chromium page content.
  • Add one page-owned post-click assertion (revealed text, changed text, toggled state) to prove ui_click affected the DOM, not just that the automation layer returned success.
  • Keep the post-click assertion inside the page content itself; avoid browser chrome, URL assertions, tabs, or address bar checks.

Harness implementation note

  • Use app-window launch (--app=) plus accessibility/startup hygiene and an isolated profile, then wait for all page-owned readiness selectors before running assertions. Only if readiness does not appear should the test harness use a narrow, test-only dismissal path for known Edge first-run/sync dialogs; if Stefan's sync popup appears, look specifically for a "Got it" button and dismiss that exact button before proceeding.
  • Close the launched Edge window first, then kill the dedicated temp-profile browser process tree only if it fails to exit promptly. Delete the temp profile after teardown.

Good public-site assertions (smoke tier)

  • Canonical placeholder or label text as accessible name (e.g., TodoMVC What needs to be done?Edit).
  • Longstanding links or buttons by visible text + stable control type.
  • Prefer public demos maintained by browser/tooling vendors over individual-maintained practice sites.
  • Use 15s+ timeouts for public pages (vs 5s local) to absorb network latency.

Anti-patterns

  • Do not depend on public practice sites whose copy or uptime is outside your control.
  • Do not mix address-bar/tab-strip/browser-chrome assertions into the first slice.
  • Do not rely on ambient browser state for default coverage; use an isolated browser profile.
  • Do not accept clickResult.Success == true as sufficient proof of Chromium interaction; require a page-content effect.

Related skills

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.