# Why Frontend Testing, Why Now — A Seatbelt for the AI Era
> The faster AI writes code, the more testing matters. In this opener of the Frontend Testing, Done Right series, we cover what tests really give you, pyramid vs. trophy strategy, and the full curriculum ahead.
**Published:** 2026-07-03 | **Updated:** 2026-07-05
---
> This is **Part 1** of the "Frontend Testing, Done Right" series. [Browse the full series](/en/series/frontend-testing-done-right/) · [Glossary](/en/posts/frontend-testing-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.
This post kicks off a new series, **Frontend Testing, Done Right**. From unit tests to Playwright E2E, accessibility checks, CI automation, and AI-assisted testing — we'll build **one demo app together and layer tests onto it, one coat at a time**. Today there's no code; instead, let's settle two questions: *why test at all*, and *what exactly are we going to build*.
---
## Where we start, and where we land
Before diving in, let's set expectations — in both directions.
**All I assume** is basic JavaScript/React and enough terminal comfort to run `npm` commands. **Zero testing experience is perfectly fine.** Every unfamiliar term gets explained right where it first appears — no "surely you know this" skips.
And the destination: finish the series, and you'll be a developer who —
- sets a **testing strategy** on your own — what to test, and how much
- designs and writes tests **from unit all the way to E2E**
- hunts down flaky tests, and ships with **accessibility and CI gates** in place
- **verifies** AI-generated code and tests instead of just trusting them
That's someone who answers "how do you test?" in an interview with their own stories — modestly put, solidly intermediate; by everyday industry standards, well ahead of the curve. Think of each chapter as one level up. Let's climb, one step at a time.
---
## What tests actually give you
If you think of tests as just a bug-catching tool, you're only seeing half of it. Here's what they really buy you:
- **Confidence**: change the code, run the suite, "it passed, we're fine." Refactoring stops being scary.
- **Living documentation**: a well-written test shows *how this function behaves*, in code. It's more honest than comments — comments quietly go stale and lie, but a test protests with a red light the moment it's wrong.
- **Faster debugging**: when something breaks, tests point at *where* first.
- **Design feedback**: code that's hard to test is usually a sign the design is tangled.
{{< img src="images/contents/why-test.jpg" alt="A seatbelt — like a seatbelt, tests let you change code without fear." caption="Photo by Remy Lovesy on Unsplash" >}}
---
## Pyramid or trophy?
"So what do I test first, and how much?" Two famous pictures enter the chat.
- **The Test Pyramid**: lots of fast **unit tests** at the base, fewer and slower **integration/E2E tests** as you go up.
- **The Test Trophy**: a frontend-flavored view that puts the most weight on **integration/component tests** that behave "like the user."
{{< img src="images/contents/pyramid-vs-trophy-en.png" alt="A side-by-side diagram of the test pyramid (wide unit-test base narrowing to E2E at the top) and the test trophy (integration and component tests emphasized largest)" >}}
The honest answer is "it depends," but this series climbs **from the bottom (unit) to the top (E2E)** — build the fundamentals first, then stack user scenarios on top.
---
## In the AI era, tests matter more, not less
This is the part I most want to talk about these days.
AI generates code **astonishingly fast**. The problem: AI-generated code is often **plausibly wrong**. It compiles, the screen renders, and then it quietly misbehaves on edge cases — or silently drops accessibility. There's simply too much code, arriving too fast, for human eyes to catch it all.
That's why **tests are the seatbelt of the AI era**. The natural partner of "AI, build this for me" is "and how do I verify it's actually right?" Generation goes to the AI; **final responsibility for verification stays with humans and tests**. In the last chapter of this series we'll go all the way: have AI *write* the tests, and learn how to verify *those*.
> If a test you dashed off is green locally but keeps flashing red only in CI (the server that automatically re-runs your checks on every push — we'll build one together later in the series) — congratulations, you've just met your first **flaky test**. Don't worry, we'll escape that swamp together later in the series.
---
## Accessibility is testing, too
Long-time readers of this blog will see this coming: **accessibility and testing are closer than they look.**
A good test that finds a button *by its role* is simultaneously verifying that *a screen reader sees it as a button*. There's a sweet spot where **a well-written test is an accessibility check** — and this series leans into it. We'll auto-scan for violations with axe-core and learn to query "like the user" with role-based selectors.
---
## What we'll build together
Talk is cheap, so we'll build. Using **React + Vite + TypeScript**, we'll create a small real-world app (a dashboard with a form, a list, search, and async requests) and layer tests onto it. Each installment's code lives in the **companion repository** ([frontend-testing-lab](https://github.com/IsaacEryn/frontend-testing-lab)) as tags — `git checkout step-N` reproduces exactly where that post ends. Curious what the finished app feels like? Try the [live demo](https://isaaceryn.github.io/frontend-testing-lab/) with zero setup, or open it in [StackBlitz](https://stackblitz.com/github/IsaacEryn/frontend-testing-lab) to explore the code right in your browser.
Here's the full roadmap:
- **Ch. 0 — Why / What**: why testing (this post) · what and how much (strategy, the coverage trap)
- **Ch. 1 — Unit tests**: project setup & Vitest · unit basics · async/errors · test doubles (mocks)
- **Ch. 2 — Component tests**: Testing Library · forms & interactions · network mocking with MSW · **baking accessibility into tests**
- **Ch. 3 — E2E & Playwright**: first scenario · locators & flakiness · fixtures & parallelism · trace debugging · **accessibility E2E with axe** · visual regression
- **Ch. 4 — Automation & quality**: GitHub Actions CI · how to read coverage
- **Ch. 5 — Testing in the AI era**: generating tests with AI · Playwright × AI · **the pitfalls of AI-written code** · retrospective
{{< img src="images/contents/roadmap-en.png" alt="A roadmap diagram showing the series' five chapters at a glance, from chapter 0 (overview) to chapter 5 (AI testing), with accessibility touchpoints starred" >}}
---
## Wrapping up
Testing isn't "something I'll do when things calm down" — it's **the thing that makes you less anxious right now**. And in an age when AI pours out code, the skill that matters as much as building fast is **verifying fast**.
Next time we'll set up the demo app and turn our very first test green. `expect(our_next_step).toBe('setup and a first green test')` — see you there.
> **Next up**: What to test, and how much — the trap of 100% coverage
> Bumped into an unfamiliar term? The [glossary](/en/posts/frontend-testing-glossary/) has them all, one line each.