Build a Reproducible Full-Page Screenshot Test: Fixture, Markers, and Acceptance Record

Testing a screenshot tool on a random news feed gives an ambiguous result. The page can change between runs, advertisements can resize, images can rotate, and personalized modules can differ by account. A reproducible test needs a controlled page with known features and an explicit expected endpoint.

Screenshot PDF provides a public full-page capture fixture. It contains no user data and is marked noindex because it is a diagnostic surface, not a search landing page. This article explains how to use it and how to build an acceptance record that another person can repeat.

What the fixture contains

The page is self-contained and does not depend on third-party images or APIs. It includes:

• a sticky header that should appear once in the finished capture;
• a fixed corner control that should not repeat through later slices;
• numbered section markers in a known sequence;
• alternating light and dark surfaces for visible seam detection;
• delayed visual blocks triggered after entering the viewport;
• a dense table for alignment and page-boundary inspection;
• a Canvas-generated stripe pattern;
• a final green endpoint that must be present.

Define the test environment

Before capture, record:

| Field | Example format | | --- | --- | | Browser | Chrome major version | | Extension | Screenshot PDF 0.0.13 | | Viewport | width × height CSS pixels | | Zoom | percentage | | Device pixel ratio | value reported by browser | | Capture mode | full page or no-split | | Theme | light or dark | | Start time | local timestamp and timezone |

Do not compare two captures made with different viewport widths as if they were the same test. Responsive layout can change section height, line wrapping, table width, and the number of slices.

Run the baseline capture

Open the fixture in a fresh tab and reload it. Do not scroll manually for the baseline. Start full-page capture and wait for the editor. Preserve the first result before attempting workarounds.

Then verify:

1. Section markers appear in ascending order with none missing.
2. The sticky header appears at the beginning and not at every viewport interval.
3. The fixed corner control does not obscure later sections.
4. Delayed blocks contain their final stripe pattern instead of an empty placeholder.
5. Table rows remain aligned and no row is duplicated.
6. Alternating backgrounds meet without a missing or repeated horizontal strip.
7. The final green endpoint is visible.

If the endpoint is missing, record the last visible marker and measure the page's CSS height. The current full-page workflow is bounded at 15,000 CSS pixels; an intentionally longer fixture or user page must be captured in sections.

Test lazy-loading behavior separately

Reload the fixture, scroll slowly from top to bottom, wait for every delayed block, return to the top, and capture again. Compare this preloaded result with the baseline.

If the baseline has empty blocks but the preloaded result is complete, the capture pipeline is functioning but the page's loading delay exceeds the wait available during automated scrolling. The correct workaround is to preload or section the page, not to label the missing image as a stitching error.

Identify seams without guessing

Use the alternating section backgrounds and Canvas stripe pattern. A missing strip creates an abrupt jump in the stripe sequence. An overlap repeats a stripe or marker. A dynamic height change misaligns content across a boundary.

Inspect at actual pixel size, not only fit-to-window. Record the approximate vertical coordinate and the markers immediately above and below the problem. This gives a developer a reproducible location rather than “somewhere near the middle.”

Verify restoration of the source page

After capture succeeds or fails, return to the fixture tab. Confirm:

• the page is at the top;
• the sticky header and fixed control are visible again;
• no capture progress element remains;
• scrolling still works;
• delayed content remains usable.

Restoration is part of the test because the extension temporarily changes visibility of floating elements. A correct output does not excuse a source tab left in a modified state.

Create a failure-minimizing reproduction

If one section fails, reproduce with the fixture first, then with a reduced local page containing only the relevant behavior. Remove private data, authentication, advertising, analytics, and unrelated frameworks. Keep the smallest CSS or JavaScript needed to trigger the issue.

Provide browser and extension versions, viewport, zoom, capture mode, marker range, expected result, actual result, and whether preloading changes the outcome. Attach cropped evidence rather than an entire private page.

Acceptance record

Use one row per run:

| Run | Markers complete | Floating UI once | Lazy blocks ready | Seams clean | Endpoint present | Source restored | | --- | --- | --- | --- | --- | --- | --- | | Baseline | pass/fail | pass/fail | pass/fail | pass/fail | pass/fail | pass/fail | | Preloaded | pass/fail | pass/fail | pass/fail | pass/fail | pass/fail | pass/fail |

Add a short note for every failure and keep the original output. A reproducible fixture cannot cover every website, but it can separate extension-wide regressions from one site's dynamic behavior.

High-quality screenshot testing is not “try several pages and see if they look fine.” It defines inputs, exposes known edge cases, records the endpoint, checks restoration, and produces a result another person can repeat without access to private information.