Reviewing & Approvals

When a session introduces visual changes, it waits for review. This article covers how to move through a session, what approving means, and how to automate approvals where a human review isn't needed.

Reviewing a session

Open the suite in TEST → Visual Tests and select the session. Snapshots are grouped into a tree using the views grouping separator and filtered by status, so you can jump straight to the ones with differences.

For each changed snapshot you see the baseline and the new version with the differences highlighted, per browser and device variant. From there you decide:

• Approve - the change is intentional; the new version becomes the baseline for subsequent sessions
• Reject - the change is a regression; the baseline stays as it was

New snapshots (views without any baseline) also await approval - approving them establishes their first baseline.

Once every changed snapshot is resolved, the session itself is resolved. See Sessions, Snapshots & Baselines for how baselines are picked.

Auto-approve

Reviewing every session manually doesn't always make sense - for example on the main branch, where changes have already been reviewed in pull requests. The Auto-approve branches setting in the suite settings takes a list of branch name patterns:

main dev release-*

Sessions created for matching branches are approved automatically and immediately become the new baseline. A common setup:

• main - auto-approved; the baseline always tracks what's deployed
• feature branches - reviewed manually; every visual change gets a pair of human eyes before merge

Human-in-the-loop

Approvals can gate your delivery process, not just the review UI:

• In Buddy pipelines, the Approve Visual Tests Session action suspends the pipeline until the session is approved - nothing deploys before the UI is confirmed. See Buddy Pipelines.
• With GitHub, the session's commit status can be a required check, blocking the merge until the visual changes are approved in Buddy. See GitHub Actions.