Frontend Testing, Done Right Subscribe to Frontend Testing, Done Right RSS feed

This is Part 22 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary What do you end up with when you stack tests onto one small app, one layer at a time? This article is the retrospective on that journey — and a map of frontend testing as a whole. The layers we stacked were these: unit tests that check whether a single function does its one job, component tests that poke at the screen the way a user would, real-browser E2E that sweeps end to end, accessibility checks that protect users who never look at the screen, and CI that runs all of it for you on every PR. By the end, we’d even gotten to verifying code and tests written by AI. ...

This is Part 21 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary AI-written code is fast, it runs, and the screen looks good. The problem is that it’s wrong in plausible ways. Two spots go empty especially often. One is accessibility — the things people who use the web without looking at a screen need. The other is what happens in moments that rarely come up — an empty search box submitted, a server returning a 500. We call these edge cases. Both fall into “nobody covers it unless you ask” territory. ...

This is Part 20 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary By now, AI “writing” test code for you feels familiar. Lately, though, it’s gone a step further — AI has started opening the browser itself, clicking through it, and checking whether things work. It’s a neat trick, but ask “so can I actually use this at work?” and the answer gets fuzzy fast. Tool names keep popping up, but there’s rarely a single piece that lays out what each one actually does and how far you can trust it. This article is that map. ...

This is Part 19 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Can you just ask AI (large language models like ChatGPT and Claude) to write your tests? Yes. Just don’t trust them as-is. AI produces plausible tests in seconds, but tends to quietly skip the boundary, failure, and accessibility cases that matter most. This article is about employing AI properly as a test-writing assistant — from getting good drafts to the checklist that proves the tests actually work. ...

This is Part 18 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Open a coverage report and four numbers stare back — Stmts, Branch, Funcs, Lines. Which one matters? This article is about reading that report: which number is honest (spoiler: branch), what to fill in from the red lines, and where to look for the team health that numbers can’t show. If you’ve been following the series, this is the hands-on follow-up to the strategy part’s point that “coverage is a reference, not a target.” First time here from a search? That’s fine too — we use Vitest, but reading a report works the same no matter which tool you’re on. ...

This is Part 17 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Tests have no power while they’re “something you run locally, sometimes.” They protect a team only once they become a checkpoint that runs on every PR. This article builds that checkpoint with GitHub Actions — a merge gate where unit tests, E2E, and accessibility checks must pass before code can merge — from a single workflow file. Never touched CI? Fine. Three minutes of vocabulary first. ...

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. ...

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. ...

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. ...

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. ...