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

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

This is Part 4 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Unit tests are where all testing begins. You put one function in front of you and nail down “this input produces this output” — the smallest, fastest kind of verification there is. This one article takes you from what a unit test actually is, through pure functions, the AAA pattern, and edge cases, with real code all the way. ...

This is Part 3 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary This is a start-to-finish walkthrough of wiring a testing environment into a React + Vite + TypeScript project — from an empty folder to the first passing test. We install Vitest, Testing Library, and jsdom, read the config line by line, turn the first test green, and map out where setup most often goes wrong. One article, complete setup. ...

This is Part 2 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Last time we talked about why testing matters. Now for the practical question: “So… what do I test, and how much?” Time is finite, and you can’t test everything. This installment is really one question, answered in three pieces: how to pick the code that’s most worth testing what coverage numbers really mean — and where they lie the testing strategy we’ll use for our demo app A diagram contrasting a perfect coverage number with a test that verifies nothing — visited is not the same as verified What to test first Not all code carries the same weight. Top priority goes to code that changes often and hurts badly when it breaks. ...

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

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