Hi there 👋

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

Running a quiz service, we got a complaint one day: “I just took the test — why does it say ‘No score’?” We checked. Their score was zero. The database clearly stored 0, the API returned 0 faithfully. The culprit was a single line in the UI code. javascript 라인 넘버 읽기: OFF 라인 넘버 읽기 기능 도움말 라인 넘버 읽기 기능 이 버튼은 스크린 리더 사용자를 위한 기능입니다. ...

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

Imagine scoring 71 on a test. Not quite “well done,” but surely enough to say “you tried,” right? Carrefour, one of France’s largest retailers, seems to have thought so too. In court, the company argued: “Our website complies with 71% of the French accessibility standard.” The court’s answer was blunt. “An e-commerce site cannot be only somewhat accessible; it must be totally accessible.” On June 4, 2026, the judicial court of Caen, France, ordered Carrefour to make its website and mobile app fully accessible within six months. Miss the deadline, and a penalty of 500 euros accrues every single day. It’s the first enforcement ruling to come out of the European Accessibility Act (EAA) regime. ...

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

“Kicking off tsc and going for coffee” — every frontend developer has made that joke at least once. That joke may have just lost its punchline. On July 8th, 2026, Microsoft shipped TypeScript 7.0: the compiler and language service, ported whole to Go and running as a native binary. If you tried the preview under the name tsgo (@typescript/native-preview), this is its stable form — a preview that was already pulling 8.5M+ weekly downloads. Official numbers put full type checks on large projects at 8–12x faster. ...

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