1
1 Comment

How do you verify a Copilot code change against the live UI?

CI tells us the code and automated tests passed. It does not prove that the intended deployment is live, the authenticated page renders correctly, or the changed journey works under a real browser session.

The pattern we are using is a small acceptance contract for the coding agent:

  1. Identify the exact build or commit.
  2. Use a named, authorized browser identity.
  3. Keep the task read-only unless a write action is explicitly approved.
  4. Check visible states in sequence instead of calling page load a success.
  5. Return screenshots, URLs, relevant console failures, and a PASS / FAIL / BLOCKED verdict.

Copilot keeps the repository context. BrowserAct provides the real-browser execution, session continuity, and evidence.

I wrote up the complete workflow here: https://www.browseract.com/blog/github-copilot-browser-automation

How are you currently closing the gap between a green CI run and a verified deployed UI?

on July 16, 2026
  1. 1

    The acceptance contract needs one more anchor: expected state must come from the same commit as the code, or screenshots can validate a stale assumption perfectly. I'd include the deployment identifier in the page or response headers, then verify one critical path plus its negative or error state under the named session. PASS should require both visible behavior and no new high-signal console or network failure.