How to Use Percy for Visual Testing of an Indian Ecommerce Website

Percy adds visual regression checks to your application tests: it captures rendered pages or components, compares them with approved baselines, and shows changes for review. For an Indian ecommerce site, start with representative shopping flows—listing, product, cart, checkout, search, and account pages—at viewports tied to your own breakpoints. Percy checks visual changes; it does not replace functional assertions, payment testing, accessibility checks, or research with customers.

1. Choose how Percy will capture your site

Create a Percy Web project for the storefront. Choose an integration path that fits the existing test setup:

• Percy SDK or framework integration: Use when tests already run in a supported framework and you want snapshots at deliberate points in a user journey. The integration guide lists Selenium, Cypress, Playwright, and Appium as examples.
• BrowserStack SDK: Consider it when you want a unified route for functional and visual testing.
• Scriptless CLI: A practical first evaluation path, or an option for static sites, unsupported frameworks, and ad-hoc snapshots.

See Percy integration options and project setup. Link your repository if you want pull-request and commit context. Add the project token as a secret in CI; never commit a live token to source control.

2. Establish a baseline and review it

1. Create the project and connect the repository if needed.
2. Install and configure the chosen SDK or CLI for your test environment, following the current official integration instructions.
3. Set the project token in your local environment or CI secret store.
4. Run the capture suite against a known-good deployment to create the first build.
5. Inspect the snapshots for the right content, route, state, and viewport. Approve the initial baseline deliberately.
6. Run the same suite on pull requests or other changes. Review diffs, fix regressions, or approve intentional design updates.

Percy builds organize snapshots and can connect review status to source control. Depending on project settings, approval can happen at snapshot, group, or build level, and repository settings can optionally make status block a merge. Agree on who reviews diffs and how branches carry baselines before making this a required check. See Percy’s visual testing overview.

3. Pick useful ecommerce pages and states

The following is a practical starting set, not a Percy-mandated list. Choose states that matter to your shoppers and are deterministic enough to compare.

Page or flow	Useful states to capture	What to inspect
Category or listing	Default listing; filter or sort applied	Product grid, card alignment, price and badge wrapping, filter layout
Product detail	Default product; selected variant	Image area, price, option state, availability and primary action layout
Cart	One item; empty cart if it is important	Totals, quantity controls, removed-item and empty states
Checkout	Stable form step; validation error state where deterministic	Field alignment, labels, error placement, buttons and summary
Search	Results and no-results state	Query heading, result grid, empty-state layout
Account	Sign-in or a meaningful signed-in state	Form geometry, validation, account navigation

Use test data and controlled accounts where possible. Make tests set the same cart contents, selected options, locale, and customer state on each run. If a state depends on a third-party service, decide whether to stub it or exclude that unstable dependency from the visual test.

4. Choose viewports based on your storefront

Percy configuration documents default widths of 375px and 1280px, and a minimum snapshot height of 1024px. Those are defaults, not evidence of Indian customer device preferences. Add widths that exercise your actual CSS breakpoints and validate them against first-party analytics. Keep the chosen widths consistent between baseline and comparison builds. See the configuration reference.

For each selected width, check whether navigation changes mode, product columns reflow, text wraps, sticky controls overlap content, or checkout fields become difficult to scan. Avoid adding many nearly identical widths without a specific breakpoint or risk to cover: every extra snapshot adds capture and review work.

5. Make snapshots stable and meaningful

• Wait for the content under test, web fonts, images, and asynchronous components to finish rendering before capture. Use the integration’s supported wait mechanisms; choose conditions that represent readiness rather than relying on a long arbitrary delay.
• Control rotating banners, randomized promotions, personalization, timestamps, changing prices, inventory, and delivery estimates in test data where possible.
• Use capture scope or ignore-region configuration for genuinely variable areas when appropriate. Do not ignore a region whose visual correctness is part of the test.
• Keep authentication and locale setup repeatable, and ensure the same route and application state are used in baseline and comparison runs.
• Capture at meaningful journey checkpoints. A screenshot taken before the page is ready creates noise rather than useful coverage.

Percy’s configuration supports scope and ignore-region options. Check the current syntax in the official configuration reference for your integration.

6. Review diffs without approving blindly

A diff proves that pixels changed; it does not by itself prove a defect. For each change, ask:

• Was this design or content change intended?
• Is anything clipped, overlapping, missing, or unexpectedly reflowed?
• Does the change look correct at each selected viewport and browser?
• Is the snapshot showing the intended account, cart, product, and locale state?

Approve reviewed intentional updates and request fixes for regressions. If your team uses pull-request status integration, define whether unresolved visual changes should block merging and who can approve baseline updates.

7. Browser coverage, reliability, and cost

Percy offers predefined browser environments; BrowserStack Automate is the option to investigate when you need a wider range of real browser environments. Check the currently supported browser matrix before setting a required coverage policy because available environments can change. The trade-off is coverage versus build size and review effort: prioritize browsers and widths based on your support commitments and observed audience.

Keep the capture suite reliable by controlling test data, waiting for stable UI, and avoiding nondeterministic content. A flaky application test can produce misleading visual changes. Percy is an additional comparison and review layer, not a substitute for testing whether checkout, payment, or other business behavior works.

Plan for snapshot volume and history retention as well as execution. The documentation states that free-plan builds expire after 30 days and other plans include one year of build history; verify current plan terms before budgeting or relying on retention. See Percy’s overview.

8. Common problems and fixes

Symptom	Likely cause	What to do
Snapshots differ on every run	Rotating content, random data, timestamps, price or inventory changes, or capture before the UI settles	Use deterministic fixtures, wait for readiness, and scope or ignore only truly variable areas.
Text or layout shifts between runs	Fonts or images have not loaded when capture starts	Wait for the relevant assets and page state with the integration’s supported mechanisms.
Snapshot shows the wrong cart or account	Authentication or test setup is inconsistent	Reset and seed the same account and cart state before each capture.
Pull request lacks Percy context or status	Repository is not linked, token is unavailable to the job, or CI integration is incomplete	Link the repository and configure the project token as a CI secret; check the integration setup and job environment.
Build has too many diffs to review	Too many redundant pages or widths, or broad unstable content	Prioritize critical states and real breakpoints, then remove redundant captures and stabilize data.
Visual check passes despite a functional failure	Visual regression checks do not assert business behavior	Keep functional assertions for navigation, cart operations, checkout, and payment flows alongside Percy.

Or skip the browser setup

If you need a standalone screenshot for a page review, documentation, or a visual reference, ScreenshotNeo is a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF. It is a screenshot alternative to try first when you want a clean capture: cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. See the ScreenshotNeo API docs.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

Use your own target URL and API key. These captures can support visual review, but they do not create Percy baselines or replace the Percy workflow described above. Sign up for 1,000 free screenshots a month, with no card required.

FAQ

Does Percy tell me whether a visual change is wrong?

No. It identifies differences against a baseline; a reviewer decides whether each change is intended or needs a fix.

Do the default viewport widths represent Indian shoppers?

No. The documented defaults are configuration values. Choose widths using your site breakpoints and first-party analytics.

Can Percy replace end-to-end checkout tests?

No. Keep functional and payment assertions for behavior, and use visual snapshots to catch rendered changes.

How long are Percy builds retained?

Documented retention differs by plan and can change. Check current plan terms before relying on a particular history period.