Percy: Review Workflow, CI & Component Testing

Builds & the Review Workflow

• A build = every percySnapshot() call captured during one full test suite run, grouped and reviewed together.

• Each build's snapshots are diffed against the baseline -- the most recently approved snapshot state for that target branch.

• A reviewer inspects each detected diff (side-by-side/overlay) and approves (intentional change, becomes new baseline) or flags it (regression to fix).

• Approving moves the baseline forward -- future builds compare against the newly-approved state.

CI Integration

# GitHub Actions -- Percy posts a status check that stays pending
# until visual diffs are reviewed, gating the PR like a failing test
name: Visual Tests
on: pull_request
jobs:
  percy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx percy exec -- cypress run
        env:
          PERCY_TOKEN: ${{ secrets.PERCY_TOKEN }}

Component-Level Testing (Storybook)

• Percy integrates with Storybook -- snapshotting individual components in each documented story/state, in isolation from a full application page.

• Narrower scope than a full-page snapshot -- catches component-level regressions without needing full app context to trigger that state.

• Similar in spirit to Chromatic, which is built specifically around Storybook for this purpose.

Snapshot Placement & Cost

• Usage/snapshot-based pricing (and reviewer burden) both argue for snapshotting meaningfully distinct UI states, not every micro-step.

• Good targets: default page view, form error state, modal open, a specific responsive breakpoint -- not every intermediate assertion.

• Percy is a managed cloud service (BrowserStack) -- vs. self-hosted tools like BackstopJS, trades operational/consistency burden for subscription cost.