Ghost Inspector Visual Regression Testing: Screenshots, Baselines, and Diffs

Ghost Inspector Visual Regression Testing: Screenshots, Baselines, and Diffs

Functional tests verify behavior — does the login flow work, does the cart update correctly. Visual regression tests verify appearance — does the login page still look like it's supposed to? These two layers of testing catch different categories of bugs, and Ghost Inspector supports both in the same platform.

Ghost Inspector's visual regression testing works by capturing screenshots during test runs and comparing them to stored baseline images. When a visual difference is detected, the test fails and shows you exactly where the pixels changed. This guide covers how the feature works, how to manage baselines effectively, and how to configure it to reduce false positives.

How Ghost Inspector Visual Regression Works

Every Ghost Inspector test captures screenshots at every step during execution. This happens automatically — you don't need to configure it. The screenshot at each step shows you exactly what the browser rendered when that step executed.

Visual regression testing extends this by introducing a baseline: a stored reference screenshot that represents the correct visual state. On subsequent runs, Ghost Inspector compares the new screenshot to the baseline pixel by pixel. If the difference exceeds a configurable threshold, the screenshot comparison fails and the overall test fails.

The process:

  1. Run a test for the first time with screenshot comparison enabled
  2. Ghost Inspector captures screenshots and stores them as baselines
  3. On subsequent runs, new screenshots are compared to baselines
  4. Differences are highlighted in a visual diff report
  5. If differences exceed the threshold, the test is marked as failing
  6. Review the diff → accept (update baseline) or reject (it's a bug)

Enabling Screenshot Comparison

Screenshot comparison is disabled by default. Enable it per test:

  1. Open a test in the Ghost Inspector dashboard
  2. Click Test Settings
  3. Enable Screenshot Comparison
  4. Set the Comparison Threshold (more on this below)
  5. Save settings

The first run after enabling comparison establishes the baseline. Ghost Inspector runs the test normally and stores the screenshots. No comparison happens on this first run.

From the second run onward, every screenshot is compared to the corresponding baseline frame.

Understanding the Visual Diff Report

When a visual difference is detected, Ghost Inspector shows a diff report in the test results. The diff view displays three images side by side:

  • Baseline — the stored reference screenshot
  • Current — the screenshot from the latest run
  • Diff — the difference image, with changed pixels highlighted in red

The diff image makes it immediately obvious where the change occurred. A text alignment shift shows as a faint red haze over the text area. A missing button shows as a solid red block where the button should be. A color change shows as a region of solid red.

The report also shows the percentage of pixels that changed. This is the number you compare against your threshold setting.

Managing Baselines

Baselines are the reference images that all future runs compare against. Getting baseline management right is the difference between visual regression testing that's useful and visual regression testing that's a constant source of noise.

When to Update Baselines

Update the baseline when a visual change is intentional. Your designer changed the button color, you're adding a new navigation item, you're updating typography. These are correct changes — the test should now compare against the new appearance.

Do not update the baseline when you're not sure if the change was intentional. Investigate first. The value of visual regression is catching unintentional changes; automatically accepting every diff defeats the purpose.

How to Update a Baseline

When a test fails due to screenshot comparison, the results page shows the diff. If the change is intentional:

  1. Click Update Screenshot on the failing step
  2. Ghost Inspector replaces the baseline with the current screenshot
  3. Future runs will compare against the new baseline

You can update individual step screenshots or update all screenshots for a test at once. Updating all is useful after a major UI redesign where many baselines need refreshing.

Baseline Versioning

Ghost Inspector stores baseline history. You can view previous baselines and revert if needed. This is useful when you accidentally accept a bad diff — you can roll back the baseline rather than having to re-establish it from scratch.

Configuring the Comparison Threshold

The comparison threshold controls how much pixel difference is tolerated before the test fails. It's expressed as a percentage of total pixels.

Choosing the Right Threshold

Threshold Behavior Best For
0% Any pixel difference fails Pixel-perfect components (icons, logos)
0.1% Tiny differences tolerated Stable, static UI with minimal dynamic content
0.5% Small differences tolerated Most production applications
1-2% Moderate differences tolerated UIs with some rendering variance
>2% Significant differences tolerated Pages with dynamic content that can't be fully masked

Start at 0.1% and raise the threshold only when you're seeing false positives from rendering variance rather than real UI changes. Raising the threshold too high makes the test useless — it will miss real visual regressions.

Why False Positives Happen

Common sources of false positives:

  • Antialiasing differences — subpixel rendering varies slightly across runs
  • Font rendering — text may render fractionally differently at different times
  • Animated elements — if a screenshot is captured mid-animation
  • Timestamps and dynamic text — content that changes between runs
  • Advertisements or A/B test variations — different content appears in different sessions
  • Scrollbar presence — sometimes a scrollbar appears and shifts layout slightly

The threshold setting handles slight rendering variance. Ignore regions handle content that genuinely changes.

Ignore Regions: Handling Dynamic Content

Ignore regions are rectangular masks that exclude specific areas of the screenshot from comparison. Any pixels inside an ignore region are not counted when calculating the difference percentage.

When to Use Ignore Regions

Use ignore regions for any content that legitimately changes between test runs but doesn't indicate a visual regression:

  • Timestamps and "last updated" text
  • User-specific data (username, account details)
  • Rotating hero images or banners
  • Live chat widgets
  • Advertisement placements
  • Date pickers showing today's date

Configuring Ignore Regions

In the test editor, navigate to the screenshot comparison settings for a step. You'll see an image of the baseline screenshot with a drawing tool. Draw rectangles over the areas you want to exclude from comparison.

You can add multiple ignore regions per step. Each region is defined by its position and dimensions relative to the screenshot.

A practical approach: run the test twice without ignore regions, look at the diff report to identify where false positives come from, then add ignore regions for those specific areas.

Step-Level vs. Test-Level Comparison

Ghost Inspector applies screenshot comparison at the step level, not just for the final state of the page. This means you can catch visual regressions that appear and disappear during a test flow — not just what the page looks like at the end.

For example: if a loading spinner appears briefly during a form submission and then disappears, a step-level comparison might catch a regression where the spinner's size or position changed, even though the final page state looks correct.

This granularity is more useful than final-state-only comparison for complex multi-step flows.

Cross-Browser Visual Comparison

Ghost Inspector runs tests on Chrome and Firefox. If you run the same test on both browsers, you get separate screenshots and baselines per browser. Visual comparison is browser-specific — Chrome and Firefox render fonts and some CSS slightly differently, so using the same baseline across browsers would generate false positives.

Configure browser selection at the suite level. If cross-browser visual regression matters to your team, create browser-specific suites and manage baselines separately for each.

Integrating Visual Regression into Your Workflow

In CI/CD Pipelines

When Ghost Inspector tests are triggered via API in a CI pipeline, screenshot comparison failures fail the test just like functional assertion failures. The build fails, and the team gets notified. This is the correct behavior — you don't want to deploy code that causes visual regressions.

The CI integration doesn't require any special configuration for screenshot comparison. Enable it in the test settings and the API results will reflect the comparison status in the screenshotComparePassing field:

{
  "data": {
    "passing": false,
    "screenshotComparePassing": false,
    "screenshotCompareDifference": 0.42
  }
}

Your CI script can check both passing (functional tests) and screenshotComparePassing (visual tests) independently if you want different handling for each failure type.

Scheduled Monitoring

Running visual regression tests on a schedule catches regressions introduced by third-party scripts, CDN changes, or server-side rendering differences that aren't tied to a deployment. If you have external JavaScript loaded on your pages (analytics, chat, support widgets), those can introduce visual changes outside your control.

A daily scheduled visual regression suite gives you visibility into these external changes before users notice them.

Balancing Coverage and Maintenance

Visual regression testing increases test maintenance overhead. Every intentional UI change requires updating baselines. The more screenshots you're comparing, the more baseline management work you have.

A practical approach:

  • Enable screenshot comparison on tests for your highest-value pages (homepage, checkout, key dashboards)
  • Don't enable it for every step of every test — focus on the steps where visual state matters
  • Assign baseline review as part of the code review process for UI changes
  • Review and update baselines in batches after planned UI updates rather than one at a time

Limitations to Know

No component-level isolation. Ghost Inspector compares full-page screenshots (or viewport screenshots for long pages). If you need to isolate visual testing to specific components, you'd need a dedicated visual testing tool like Chromatic or Percy.

No cross-device comparison. Ghost Inspector runs on desktop browser sizes. If you need mobile visual regression, you'd need to configure the test viewport size and manage separate mobile baselines.

Baseline drift. If you update baselines without careful review, you can accept regressions as the new normal. The baseline becomes less meaningful over time. Maintain discipline about when you update versus investigate.

No built-in perceptual hashing. Ghost Inspector uses pixel comparison. Perceptual hashing algorithms (which more closely match human visual perception) are available in specialized tools but not in Ghost Inspector.

For teams that need component-level visual testing, cross-device comparison, or more sophisticated comparison algorithms, a dedicated visual regression tool integrated with your existing test setup may serve you better. For teams that want visual regression as part of the same tool handling their functional browser tests, Ghost Inspector's built-in capability is a solid starting point that requires minimal additional setup.

Read more

Start now free