Why frontend developers don't wanna write e2e tests

Source: Dev.to

Introduction

If you clicked on this article because of the title, you’re probably one of those front‑end devs who hate writing tests – no worries, I’m in the same boat.

A recent survey showed that the majority of front‑end teams don’t write tests. That got me wondering:

• Why is testing in the front‑end so universally despised?
• What kinds of tests actually matter?
• Is there a faster, easier way to get tests written?

Below are the three main reasons I’ve seen, followed by a quick look at why E2E tests are still essential and how we can make them less painful.

1️⃣ Writing tests feels slow and boilerplate‑heavy

Most developers see testing as a chore rather than a benefit. When the test file ends up longer than the feature itself, something feels off.

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:

• Define the browser environment.
• Mock API calls.
• 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 trying to test. There’s no “quick‑record‑and‑go” option; 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 – a massive time sink.

2️⃣ Developers don’t know what to test

If you work on the back‑end, testing is usually straightforward: send an input, check the DB or API response. It’s binary and clean.

In the front‑end, 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 200 ms?
• 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?

This leads to analysis paralysis. Without a clear “blueprint” of what matters, we either:

1. Try to test everything – resulting in a maintenance nightmare, or
2. Test nothing – because we’re overwhelmed.

After spending hours wrestling with a complex UI, the last thing you want is another three hours guessing which DOM elements are “important enough” to assert. It feels like throwing darts in the dark.

3️⃣ Front‑end moves faster than back‑end

Front‑end code changes constantly: buttons move, layouts tweak, CSS classes get renamed. A “tiny” UI change that takes two minutes can break a whole suite of tests.

You end up spending more time updating selectors and fixing “broken” tests than shipping features. Eventually the maintenance overhead becomes so painful that many teams simply stop writing tests to keep up with the development pace.

Why E2E Tests Matter

In the front‑end, E2E tests matter more than unit tests. You can have 100 % coverage on a button component, but that won’t tell you if:

• The API failed to load.
• 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 simulate a real person on a real device, checking that the “Happy Path” (e.g., logging in, clicking “Buy Now”) works from start to finish. They’re the safety net that lets us click “Deploy” on a Friday afternoon and go home without fearing a production meltdown.

The Problem with Modern E2E Testing

You might think tools like Cypress and Playwright have solved everything. They’ve certainly improved the experience, but the fundamental pain points remain:

• Flakiness – A test fails in CI, passes on a rerun without any code change. This erodes trust: Is the code broken, or was the API just 50 ms slower?
• “Shadow App” Maintenance – Even with modern tools, you still end up writing a lot of scaffolding (environment setup, mocks, auth handling) that feels like a separate app you must keep in sync with the real one.

A Faster Way to Write Meaningful Tests

Below is a lightweight approach that reduces boilerplate and focuses on what truly matters:

1. Use a declarative test runner (e.g., Playwright Test with its built‑in fixtures).
2. Leverage auto‑generated selectors (data-test-id attributes) to avoid brittle CSS selectors.
3. Record‑and‑replay a user flow once, then let the runner generate the test skeleton.
4. Mock only what you need – use network interception to stub external APIs on a per‑test basis, rather than building a full mock server.
5. Keep tests small and focused – one test per user story (e.g., “login → add to cart → checkout”).

With this pattern you can spin up a reliable E2E test in under 5 minutes per feature, without the overhead of a full “Shadow App”.

TL;DR

• Front‑end testing feels slow, confusing, and fragile.
• The real value lies in E2E tests that validate the user’s journey.
• Modern tools help, but you still need a strategy that minimizes boilerplate and flakiness.

Give the declarative, record‑first approach a try – you might actually start enjoying writing tests again. 🚀

The Problem with Modern E2E Tools

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.

Common Pain Points

• Tied to implementation details – If you rename a class or change a data-testid, you have to hunt through your test files to fix them. You’re basically maintaining two apps at the same time.
• Steep learning curve – To use these “modern” tools properly, you must learn async/await patterns, complex locators, and how to handle headless‑browser contexts. That’s a lot to ask of a frontend dev who just wants to make sure their UI doesn’t break.

In short, the current state of E2E testing feels cumbersome and brittle.

Introducing Symphony

After years of fighting with flaky selectors and spending more time in Cypress docs than in my actual codebase, I decided to build something better.

Symphony is a tool that makes 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.

Project: Symphony on GitHub

Why Symphony Is a Game‑Changer

• Zero Boilerplate – No more setting up browser contexts or massive beforeEach blocks. Define the flow and run it.
• Built for Speed – 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 open 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.