Applitools Eyes Batch Testing Across Multiple Website Pages

To batch-test multiple website pages with Applitools Eyes, add a named visual checkpoint for each page or meaningful UI state, give the related tests the same batch identity, run the suite, and review the grouped results in the Eyes dashboard. If Playwright runs tests in parallel, pass one stable batch ID to every worker; a different ID in each worker can split one logical run into several batches.

This guide uses the Applitools Playwright integration for its runnable example. The core workflow also applies to other Eyes SDKs, but configuration syntax varies by framework and SDK version. Check the current documentation for the SDK installed in your project before copying configuration across frameworks.

1. Understand what a batch groups

A batch is a dashboard grouping for related test results, often one execution of a test suite. It groups tests for review; each test and its checkpoint comparisons remain available inside the batch. It does not replace your browser test framework or make page navigation happen automatically: your test navigates and establishes the page state, then Eyes captures a checkpoint.

Choose a batch identity based on what you want to review together. Tests from one CI run or suite run can share an identity. Give a separate run or independently reviewed group a distinct identity. For reliable automation, make the identity explicit rather than depending on implicit defaults. Applitools describes batch setup and test grouping in its batch documentation and Playwright integration guide.

2. Install and configure the Playwright integration

Use the Eyes Playwright SDK that matches your project’s Playwright setup. The following example follows the fixture-based integration style in the official Playwright guide. Install and configure the SDK according to that guide for the current package and project version.

// tests/pages.spec.ts
import { test } from '@applitools/eyes-playwright/fixture';

const batchId = process.env.EYES_BATCH_ID;
if (!batchId) {
  throw new Error('Set EYES_BATCH_ID to a stable ID shared by this test run.');
}

test('public pages visual checks', async ({ page, eyes }) => {
  await page.goto('https://example.com/');
  await page.getByRole('heading').waitFor();
  await eyes.check('Home page', { fully: true });

  await page.goto('https://example.com/pricing');
  await page.getByRole('heading').waitFor();
  await eyes.check('Pricing page', { fully: true });

  await page.goto('https://example.com/contact');
  await page.getByRole('heading').waitFor();
  await eyes.check('Contact page', { fully: true });
});

Configure the batch where the Eyes Playwright fixture is initialized. The fixture documentation exposes a batch property in eyesConfig; exact object construction should follow the installed SDK version. A representative configuration shape is:

// playwright.config.ts — adapt imports and BatchInfo construction to your SDK version
import { defineConfig } from '@playwright/test';
import { BatchInfo } from '@applitools/eyes-playwright';

const batchId = process.env.EYES_BATCH_ID;
if (!batchId) throw new Error('Set EYES_BATCH_ID before starting the suite.');

export default defineConfig({
  use: {
    eyesConfig: {
      batch: new BatchInfo({ id: batchId, name: 'Website visual checks' }),
    },
  },
});

Applitools’ fixture guide documents the eyesConfig.batch setting. BatchInfo constructor and import details can change between SDK versions, so treat this configuration snippet as an integration shape and verify exact syntax against the current guide for your installed version. Keep the batch ID consistent with the environment variable used by the suite.

3. Add checkpoints for pages and states

Each call to eyes.check() records a visual checkpoint at the browser state your test has established. Give checkpoints names that identify both the page and, when relevant, the state. For example, “Pricing page — annual plan selected” is more useful in review than “Screenshot 2.”

Use the capture scope that fits the test:

Full page: set fully: true when the comparison should include content beyond the viewport.
Element or region: use the SDK’s region option when a component is the target and surrounding page changes should not affect the check.
Match level: choose the comparison behavior supported by your SDK to suit the page. Use stricter matching for stable, controlled content; account for expected variation on dynamic pages.
Ignored regions: mark volatile areas such as rotating content as ignored when their changes are outside the assertion’s purpose. Avoid ignoring large areas that could conceal meaningful regressions.

The Playwright integration documents full-page capture, regions, match levels, ignored regions, and named checkpoints. Establish the state before the checkpoint: wait for the relevant heading, component, or application signal, and stabilize animations or changing data when those are not part of the behavior under test.

4. Run the suite and keep parallel workers in one batch

Set a batch ID once for the logical run, then make it available to every Playwright worker. For a local run:

EYES_BATCH_ID="website-visual-$(date +%Y%m%d-%H%M%S)" npx playwright test

In CI, generate the ID once in the job or workflow and expose the same value to all workers and shards that should appear together. Do not generate a fresh random ID inside each worker. Playwright workers run in separate processes, so ordinary in-memory global state is not shared between them. If each process constructs a different batch identity, the dashboard may show multiple batches for one logical suite run. The Applitools guidance on parallel Playwright tests and batch IDs explains this failure mode.

Create a unique ID for a distinct suite execution, such as a CI run identifier.
Set it at the parent job or workflow level before launching workers or shards.
Pass that same value into the Eyes batch configuration in every process.
After execution, check the dashboard batch list to confirm the expected tests are grouped together.

For tests that intentionally belong to separate review groups, assign distinct IDs deliberately. Avoid reusing a fixed ID indefinitely if it would combine unrelated runs and make review confusing.

5. Review results in the Eyes dashboard

Open the batch for the run and inspect its test statuses. Open individual tests to review checkpoint steps and compare baseline images with the new captures. A batch helps organize review; it does not mean every difference is a defect or that every checkpoint has passed automatically. Examine visual changes before accepting a new baseline so an intended update is not confused with a regression. See Applitools’ dashboard documentation for batch and test details.

6. Adapt the pattern to another framework

Applitools lists integrations for frameworks including Playwright, Selenium, Cypress, and WebdriverIO. Keep the same conceptual sequence: navigate and establish the page state with the framework, configure one batch identity for related tests, add named Eyes checkpoints, and review results together. Use the SDK guide for your language and framework for exact APIs; do not assume that a JavaScript batch snippet translates unchanged to Python, Java, or another SDK.

Before porting the workflow, verify three things in the current SDK documentation: how the framework configures a batch, how the batch identity is passed into worker processes, and which checkpoint controls are available for full-page, region, and dynamic-content handling.

7. Troubleshooting

Symptom	Likely cause	Fix
One CI run appears as several batches	Workers or shards received different batch IDs, or each process created its own ID.	Generate the ID once in the parent CI job and pass the same value to all processes that belong together.
Tests from separate runs appear together	A fixed batch ID is reused across unrelated executions.	Generate a distinct ID per logical run while keeping it shared across that run’s workers.
No useful checkpoint appears for a page	The test navigated away, captured before the intended state, or used an unclear checkpoint name.	Wait for the page’s relevant state, call `eyes.check()` there, and use a page or state-specific name.
Full-page comparison misses lower content	The checkpoint was captured at viewport size rather than with full-page capture enabled, or content had not loaded.	Use the SDK’s full-page option such as `fully: true` and wait for lazy or asynchronous content that matters to the test.
Visual diffs change on every run	Dynamic data, animation, or rotating content is included in the comparison.	Stabilize test data and page state; use a region or ignored region for expected volatile content where appropriate.
Configuration or import errors after an SDK upgrade	The example’s BatchInfo or fixture API does not match the installed SDK version.	Check the current Playwright integration documentation and align the import and batch construction with the installed package.
A batch is empty or incomplete	Tests failed before checkpoints ran, or some workers did not receive the Eyes configuration.	Inspect test-run errors and confirm every worker uses the same fixture setup, API key configuration, and intended batch ID.

8. Performance, reliability, and cost considerations

Batching is an organizational choice for reviewing related results; it does not itself make browser navigation or visual capture faster. Runtime depends on the pages, browser automation, number of checkpoints, full-page content, parallelism, and the stability waits your tests require. Keep waits tied to meaningful application state rather than adding arbitrary delays, and capture only the pages and states needed to answer the visual question.

Parallelism can reduce elapsed test time, but it makes configuration propagation more important: every worker must receive the intended batch identity and Eyes configuration. Treat the batch ID as run metadata, generate it once, and log it with the CI run so a dashboard batch can be traced back to its execution. Recheck SDK syntax when upgrading because the cited general batching article is older and SDK APIs may evolve.

Costs and quotas depend on your Applitools account and plan. The research sources do not establish current plan prices or usage limits, so check the current Applitools account and pricing information before estimating a suite’s cost.

Or skip the browser setup

If your immediate need is a screenshot of a page rather than an Eyes visual regression suite, ScreenshotNeo is a website screenshot API and MCP server. One GET request returns an image or PDF. Its API accepts screenshot options such as full-page capture, a CSS selector, viewport and device settings, wait conditions, custom CSS or JavaScript, and cookies or headers. See the ScreenshotNeo API documentation for parameters.

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}`);

ScreenshotNeo accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each of those steps can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers report the page verdict and whether the request was billed. Its MCP server includes take_screenshot, get_page_info, and capture_pdf for AI agents. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

FAQ

Does one Eyes batch mean one checkpoint?

No. A batch can contain multiple tests, and tests can contain their own named checkpoints. Use the grouping for suite-level review and checkpoint names for page or state-level detail.

Should every page be a separate test?

Use the structure that fits your existing suite and review needs. The essential requirement is that each intended page state reaches a named checkpoint and related results receive the same batch identity.

Can one batch ID be used by parallel Playwright workers?

Yes. That is the expected approach when the workers’ results belong in one batch. Pass the same explicit ID to each worker process.

Can ScreenshotNeo replace Eyes batch testing?

No. ScreenshotNeo captures pages through an API; the Eyes workflow groups visual test results and baseline comparisons from an automated test suite. Choose based on whether you need a screenshot response or a visual regression review workflow.