Percy: uses, strengths, and limitations

In plain words

Percy plays spot-the-difference with your interface. It takes a picture of each screen, compares it with the version you previously approved, and shows you exactly what moved. It catches the things functional tests never notice: overlapping text, a button pushed off the edge, a layout that collapses at tablet width.

Crucially, it does not decide whether a change is wrong — a person reviews and approves. That is the right division of labour.

What using it looks like

1. Add a snapshot call to tests you already have.
2. Run once to create the approved baseline images.
3. On the next change, Percy shows a side-by-side view of anything that moved.
4. Approve intended design changes; reject regressions.
5. The approved version becomes the new baseline.

Because it renders at several widths, one snapshot can tell you whether a change broke the mobile layout — a class of bug that is otherwise found by customers.

What to watch out for

• Changing data creates false alarms. Pin the content your snapshots show, or you will review noise every day.
• Animations, timestamps and rotating banners must be frozen before capture.
• Review volume is a real cost. Snapshotting every page produces more differences than a team will genuinely look at.
• Bulk-approving to clear a backlog quietly approves real defects. It only takes once to lose the value.

Common questions