Skip to content
Visual Regression Testing — Screenshot Comparison thumbnail

Visual Regression Testing — Screenshot Comparison

This is Part 16 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Ever had every test green while the screen was broken? Logic fine, one CSS rule collapsing the layout? Visual regression testing stores a reference screenshot (the baseline) and compares pixels, automatically catching “regressions only eyes can see.” It’s built into Playwright — one line to start — but there’s a knack to stable shots and an ambush called environment differences. All covered here. ...

Published date: 2026-07-29 · Reading time: 11 min · Word count: 2151 words · Author: Isaac
Accessibility E2E — Scanning with @axe-core/playwright thumbnail

Accessibility E2E — Scanning with @axe-core/playwright

This is Part 15 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Whether a button has a name, you can tell by looking at that button. But whether its text contrasts enough with the background, whether the page declares a language, whether an id is duplicated — you can’t tell from one element. You have to look at the whole screen, and at the state it’s actually rendered in. That’s tiring to do by eye every time, which is exactly why you want an automated checking engine. ...

Published date: 2026-07-27 · Reading time: 11 min · Word count: 2248 words · Author: Isaac
Traces, Debugging, and Retries — Tracking Down the Cause thumbnail

Traces, Debugging, and Retries — Tracking Down the Cause

This is Part 14 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary “Works on my machine, red on CI.” The homework of everyone who operates E2E, and the prime cause of console.log wallpaper. Playwright ships three tools that solve this mystery with evidence: traces that rewind the failure whole, a UI mode that time-travels, and retries used as a signal. We pack all three today. Series readers: this is insurance for the day your E2E breaks. Searchers: this is the emergency kit for the test that’s broken right now. Examples are self-contained. ...

Published date: 2026-07-22 · Reading time: 7 min · Word count: 1294 words · Author: Isaac
Fixtures, Auth Reuse, and Parallel Runs thumbnail

Fixtures, Auth Reuse, and Parallel Runs

This is Part 13 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Past ten E2E tests, two things start to hurt: the setup code copy-pasted into every test, and the suite slowing down as it runs in sequence. Playwright’s fixtures (a mechanism that injects repeated setup into tests) and parallel execution solve both at once — this article covers custom fixtures, auth reuse (storageState), and the safety rules for parallelism. ...

Published date: 2026-07-21 · Reading time: 3 min · Word count: 1355 words · Author: Isaac
Locators and auto-wait — Taming Flaky Tests thumbnail

Locators and auto-wait — Taming Flaky Tests

This is Part 12 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Flaky tests — the code hasn’t changed, yet some days it passes and some days it fails. It’s the first illness every team catches when adopting E2E, and left untreated it breeds a scary culture: “that one again? just rerun it.” Fortunately the cause is usually singular: finding elements too early, or the wrong way. This article pulls that root out with Playwright’s locators and auto-wait. ...

Published date: 2026-07-18 · Reading time: 4 min · Word count: 1692 words · Author: Isaac
Getting Started with Playwright E2E — Your First Scenario thumbnail

Getting Started with Playwright E2E — Your First Scenario

This is Part 11 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Playwright is an E2E testing tool that drives real browsers (Chromium, Firefox, WebKit) with code. E2E (End-to-End) is exactly what it says — reproducing the entire flow of a user visiting, searching, and seeing results, in an actual browser. This article goes from install to a passing first scenario in one sitting. If you’ve been following the series, this is where the stage gets bigger — we’ve been playing inside jsdom, a pretend browser; now we open a real one. New here? No problem: we start from installation, and you can put any Vite/React app of yours where the demo app sits. (Demo UI strings are Korean — 대시보드 = “Dashboard”, 검색 = “Search”.) ...

Published date: 2026-07-18 · Reading time: 4 min · Word count: 1781 words · Author: Isaac
Testing Terms, All in One Place — A Frontend Testing Glossary (Appendix) thumbnail

Testing Terms, All in One Place — A Frontend Testing Glossary (Appendix)

This is the appendix to the “Frontend Testing, Done Right” series. Whenever you hit an unfamiliar term in the series, come back here. Browse the full series Learning frontend testing means getting buried in unfamiliar words. How is a mock different from a stub? When do getBy and queryBy part ways? Why shouldn’t you take a coverage number at face value? This one page collects all of those terms — and each entry goes beyond “what it is” to “why it matters” and “when you’d use it.” ...

Published date: 2026-07-04 · Updated 2026-07-27 · Reading time: 19 min · Word count: 3880 words · Author: Isaac
Why Frontend Testing, Why Now — A Seatbelt for the AI Era thumbnail

Why Frontend Testing, Why Now — A Seatbelt for the AI Era

This is Part 1 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary “Tests? But it already works.” We’ve all said it — or heard it. I said it for years. Look at the screen, click around, “yep, works,” done. But then the features pile up, and every time you touch the code a little voice asks, “if I change this, what breaks over there?” That creeping anxiety is exactly the moment tests become worth their price. ...

맨 위로