Loading today’s stories
Build1 distinct publisher3 min readUpdated
A dev.to walkthrough pins dashboard API responses with page.route, then asserts with toHaveScreenshot. The mock, not the assertion, is what makes the baseline worth keeping.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Abigail Armijo has published a walkthrough on dev.to of a dashboard visual-regression suite that freezes every API response with Playwright request interception, then compares a screenshot using the framework's built-in `toHaveScreenshot` assertion [1][5]. The assertion is one line; the mocking is the part that decides whether the baseline is a signal or a coin flip [4].
The motivating defects are the ones assertions on the DOM tend to miss. Armijo cites a chart that stopped rendering after changes to other charts, and a Google Maps integration where a change left one button overlapping another [3]. She also says plainly that she is not a fan of mock APIs in end-to-end tests, but that a dashboard whose API data changes daily leaves little choice if you want to know the charts drew correctly [2].
The mock helper is unremarkable in the good way: `page.route` on a glob of `**` plus the API path, then `route.fulfill` with a status defaulting to 200, `application/json`, and a stringified fixture [10]. The dashboard page object calls it per endpoint, so `/api/collection/summary` returns a fixed payload such as `{"Amount": 56046.00, "AverageDaysPastDue": 35}` [11], with further fixtures for top-five and top-ten queries [13]. The test itself reuses a stored admin session from `.auth/admin.json`, mocks all APIs, navigates, waits for charts to be visible, and only then snapshots [12].
The screenshot side is a thin wrapper: one method for the full page, one for a locator, each defaulting to a 5,000 ms timeout and `maxDiffPixels` of 100, with tolerance settable in pixels or as a percentage [8]. Armijo says she deliberately keeps that tolerance very small so any design change trips the test [15]. Both methods wrap the assertion in `test.step` with a description that names the snapshot and the pixel budget, which is what makes an HTML report readable when a suite of these fails [9].
The commercial framing is where operators should read carefully. The post names Percy by BrowserStack, Applitools Eyes and Sauce Labs Sauce Visual as the paid options, and Playwright's comparison as a built-in free one [6][5]. That is three vendors against one assertion [7], but the post does not benchmark them or compare features [16]. What it demonstrates is that the mechanical core - deterministic data in, pixel diff out - is already in the test runner you are probably running.
The bill arrives as adjudication, not licence fees. Armijo's own example failure was an intentional change: an older build showed segment details on click, and the new one renders a table for accessibility [14]. The tool cannot tell you that; a person has to, and then update the base snapshot, which she notes is the standing cost of the approach [4].
Two things to watch before copying this. The post does not say where the baselines were generated or on what operating system and browser the suite runs [17], and that is the variable that decides whether a 100-pixel budget [8] holds in CI or produces a queue of diffs nobody reads. The second is scope: element-level snapshots [8] on individual charts fail more usefully than one full-page image, because a full-page diff tells you something moved, not what.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
She cites two incidents motivating visual testing: after changes to some charts, one chart was not displayed; and in a Google Maps integration, changes caused one button to overlap another.
A dev.to post by Abigail Armijo titled "Solution to Challenge 3 - Visual Testing with API Mocking" describes a dashboard visual-testing setup that combines API mocking with screenshot comparison in Playwright.
Armijo writes that she is not a big fan of mock APIs for end-to-end tests, but that when testing a dashboard with daily API changes you need to ensure the charts are displayed correctly.
The described approach is to mock the API so it returns the same data, save an image snapshot, and compare the current website against it; if the UI changes, the base snapshot must be updated.
Playwright includes a built-in free option to compare screenshots, invoked as await expect(page).toHaveScreenshot().
The post names Percy by BrowserStack, Applitools Eyes and Sauce Labs (Sauce Visual) as paid visual testing tools.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Runnable first-hand code, single unverified source
The mechanics are strongly evidenced because the post publishes the actual helper and spec code, so the API surface (toHaveScreenshot, page.route, route.fulfill, defaults of 5,000 ms and 100 pixels) can be read directly. Everything beyond the code is a single practitioner's account with no second source, no metrics, and no environment disclosure, which caps how far the evidence carries.
One practitioner's suite, no scale signal
Adoption evidence exists but is minimal: the author demonstrably runs this pattern on a real dashboard and it has already flagged a genuine UI change. There is no information on team size, suite size, CI usage, or any other user of this specific pattern, so it registers as a single disclosed usage rather than diffusion.
Framing outruns the comparison the post makes
The post's own claims are modest, but the equivalence implied by listing three paid vendors and then a single free assertion is not substantiated anywhere: there is no capability, accuracy, or cost comparison, and no disclosure of the baseline environment where hosted visual-testing services typically add value. That leaves the free-replaces-paid framing mildly overstated relative to what the material demonstrates, though the working code keeps the gap small.
Personal challenge write-up, no disclosed vendor stake
The source is a first-person solution to a community challenge published on a developer blogging platform. It promotes no product of the author's, discloses no vendor relationship, and names competing paid tools neutrally in a single line, so the visible incentive is reputational rather than commercial.
High on mechanics, low on generalisation
Confidence is high that the described setup exists and works as printed, because the code and a real failing diff are shown. It is low that the pattern generalises to teams needing cross-browser, cross-OS baselines or that it substitutes for paid tooling, since the cluster has one publisher, one practitioner, no metrics, and no environment detail.
build
Yadda 3's real artifact is not the code, it is the rules the agent could not rewrite1 distinct publisher
build
A build step instead of a backend: 1,025 records, 8 locales, no runtime API1 distinct publisher
build
Allow-list the closed set, block-list the open one: 193 thin geo pages, one gate1 distinct publisher
build
A GAN beauty filter is a device budget allocation, not a feature toggle1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 15, 2026