If you have clicked on this article by reading the title, that means you are one of those frontend devs who hate writing tests, no worries, I am also one of you.
Recently I came across a survey which showed that majority of the frontend teams don't write tests. That made me think, why is that, why is it that writing tests in frontend is mutually hated upon, and I came across these few points.
This is not just a rant, but I am also gonna talk about what kind of tests really matter and an easier option to write your tests fast.
1) Writing test is slow and involves too much boilerplate
Most developers see writing tests as a chore rather than a benefit, and honestly, can you blame them? When the test file ends up having more lines of code than the actual feature you just built, something feels wrong.
The biggest momentum killer is the boilerplate.
Before you even get to the “user flow” you actually care about, you have to do a bunch of administrative work:
You have to define the browser environment.
You have to mock the API calls.
You have to handle authentication states (the classic “log in before every test” struggle).
By the time you’ve finished setting the stage, you’ve forgotten what you were even trying to test in the first place. There’s no “quick way” to just record a flow and move on. Instead, you're stuck writing infrastructure code for a headless browser. It feels like you're building a “Shadow App” just to keep your real app in check—and that’s a massive time sink.
2) Developers don't understand what to test
If you’re working on the backend, testing is usually straightforward: you send an input, and you check if the database updated or the API returned the right JSON. It’s binary. It’s clean.
But in the frontend? It’s a mess.
When you finish a feature and sit down to write a test, a million questions pop up:
- Do I test that the button is blue?
- Do I test that the loading spinner appears for exactly 200ms?
- Do I test the internal state of my React component, or just what the user sees?
- What happens if the API fails? Do I need a test for every single error toast?
For most of us, this leads to Analysis Paralysis. Since we don't have a clear “blueprint” of what matters, we either try to test everything (which leads to a maintenance nightmare) or we test nothing because we’re too overwhelmed to start.
When you’ve just spent the last 6 hours wrestling with a complex UI feature, the last thing you want to do is spend another 3 hours playing a guessing game about which parts of the DOM are “important enough” to assert. It feels like throwing darts in the dark.
3) Frontend moves faster than backend
As we discussed before, frontend is not binary and straightforward like backend. Plus, the thing in the frontend moves a lot faster than it does in the backend. In the backend, an API contract rarely changes. But in the frontend, we’re constantly moving buttons, tweaking layouts, and renaming CSS classes to improve UX.
So, when you make a “tiny” UI change that takes 2 minutes, your test suite suddenly breaks. You end up spending more time updating selectors and fixing “broken” tests than actually shipping features. Eventually, maintenance becomes such a headache that it’s easier to just stop writing them entirely so you can keep up with the pace of development.
Why E2E tests matter
In frontend, E2E tests actually matter more than your unit tests. Think about it: you can have 100% test coverage on a button component, but that won't tell you if the API failed to load or if a transparent div is accidentally covering the entire screen.
At the end of the day, we only care about one thing: Is the user’s experience broken? E2E tests are the only ones that actually simulate a real person on a real device. They check if the “Happy Path” (like logging in or hitting 'Buy Now') actually works from start to finish. We hate writing them, but they’re the only reason we can click “Deploy” on a Friday afternoon and actually go home without worrying about a production meltdown.
The problem with modern E2E testing
You might be thinking, “But we have tools like Cypress and Playwright! Aren't they supposed to fix this?”
They definitely made things better, but they didn’t solve the fundamental problem. Even with the “modern” stuff, we’re still running into the same brick walls:
The Flakiness Factor: You run a test in CI, and it fails. You run it again without changing a single line of code, and it passes. T“flakiness”ess" destroys your trust. Is the code actually broken, or was the API just 50ms slower this time?
The “Shadow App” Maintenance: As we talked about, these tools are still tied to your code. If you rename a class or change a data-testid, you have to go hunting through your test files to fix them. You're basically maintaining two apps at the same time.
The Learning Curve: To use these “modern” tools properly, you have to learn about async/await patterns, complex locators, and how to handle headless browser contexts. It’s a lot to ask of a frontend dev who just wants to make sure their UI doesn't break.
In short, even the best frameworks today still feel like they were built for Automated Testers, not for Frontend Developers who need to move fast. They focus on how to test, but they don't help with the pain of keeping those tests alive.
Something to help you write E2E test faster
After years of fighting with brittle selectors and spending more time in Cypress docs than in my actual codebase, I decided to build something better.
I’m working on a tool called Symphony.
The goal of Symphony is simple: Make E2E testing feel like a natural part of the frontend workflow, not a second job. Instead of writing complex, imperative code to click buttons and wait for loaders, Symphony lets you define your user flows in a way that actually makes sense. It uses a YAML-based DSL—which basically means you describe your test steps in plain, human-readable English.
Here is why I think it’s a game-changer for devs like us:
Zero Boilerplate: No more setting up browser contexts or massive beforeEach blocks. You just define the flow and run it.
Built for Speed: It’s designed to be fast to write. If it takes you 2 minutes to build a feature, it shouldn't take you 20 minutes to test it.
Readable by Anyone: Because the tests are written in a simple YAML format, even a PM or a designer can look at the test file and understand exactly what is being covered.
Symphony is built for the "lazy" developer (the best kind of developer) who wants the safety of E2E tests without the nightmare of maintenance.
Top comments (0)