Testing Subscribe to Testing RSS feed

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

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

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

This is Part 10 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary What comes to mind when you hear “accessibility testing”? Hiring a consultant, adopting a dedicated audit tool, working through checklists hundreds of items long… it’s easy to picture something big. Surprisingly, though, half of accessibility verification comes free just from writing component tests well. This article is that principle plus the practice — flushing out div buttons, naming icon buttons, and guarding focus that vanishes into thin air. ...

This is Part 9 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary The moment a component starts calling an API, tests get shaky. A slow server makes them slow, changed data breaks them, and offline they’re wiped out. MSW (Mock Service Worker) intercepts network requests at the boundary and returns prepared responses, solving the problem at its root. This one article covers installation, handlers, and simulating both success and failure. ...

This is Part 8 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary A button isn’t really tested until you press it; an input, until you type into it. user-event is the member of the Testing Library family in charge of reproducing interaction — even a single click walks through focus changes and key-event order just like a real browser, closing the gap where “it works when a user does it, but not in the test.” In this article we build typing and clicking tests from scratch. ...

This is Part 7 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Testing Library is the de facto standard for component testing in React and beyond. But the real substance of this tool isn’t its API — it’s one philosophy. The moment you start testing components, temptations appear: “should I find it by class name? peek at internal state?” Testing Library answers firmly: do what the user does. In this article we’ll see what that philosophy means, the order for choosing queries, and why this approach is inseparable from accessibility — all while building a search component from scratch. ...

This is Part 6 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary “I tested it with a mock” — that phrase actually bundles four different concepts (stub, spy, mock, fake) into one word. This single article sorts out those four terms, shows how one Vitest vi.fn() covers all of them, and settles the question of how far to go with faking. Sort it out once and your eye for reading and writing test code gets much sharper. ...

This is Part 5 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Real-world code waits. It waits for API responses; it waits for timers. That makes async testing the first wall most frontend developers hit — but the reason it feels hard boils down to a single question: “when do you verify?” Grade the answer sheet before the answer arrives, and you’re grading a blank page. This one article packs the complete toolkit for code that waits: Promise verification (resolves/rejects), fake timers, and the failure cases. ...