Every team has that one person, or two, who insists that “frontend tests are a waste of time.”
They might say E2E tests are flaky, or that QA already does the job. But deep down, skipping tests isn’t a bold time-saving move; it’s a long-term productivity trap.
Here’s how to win the argument (and save your project from endless regressions).
Why Testing Matters, even on the Frontend
1.Tests catch regressions before your users do
Frontend changes are deceptively simple. You tweak a component or update an API call, and suddenly the login form stops working.
Having automated tests for critical flows (login, checkout...) ensures that your app’s core functionality never silently breaks. Without tests, the real testers are your users, and they’re the worst kind of testers.
2.They actually save time
Fixing a bug found in production takes exponentially more time than catching it during development. Manual QA can’t rerun every scenario on every release, but a test suite can, in seconds.
So while writing tests feels slow upfront, it pays off every sprint.
3.They make refactoring safe
When your codebase grows, refactors are inevitable. Without tests, developers fear touching anything. With tests, you can confidently restructure, optimize, or modernize your code, knowing that your safety net will catch regressions instantly.
4.They force better code design
Writing testable code means separating responsibilities and avoiding hidden side effects. Tests naturally lead to cleaner, more modular, and easier-to-understand components.
In the long run, this reduces onboarding time for new developers and increases overall code health.
5.You don’t need 100% coverage
Nobody’s asking for full-blown test coverage. Start small: Cover only the key integration flows.
Common Objections, and How to Defeat Them
- "Tests are too fragile": Badly written tests can be unstable, but using modern tools, and using them well, makes them reliable and maintainable.
- "We don’t have time": Skipping tests saves time only in the short term. Bugs found later cost far more to fix and slow development over time.
- "QA already checks that": QA should focus on exploratory and edge-case testing, not on repeating the same core flows every release.
- "Our app changes too often": Frequent changes increase the risk of regressions. Well-structured tests provide confidence and prevent hidden breakages.
- "Tests slow us down": Full E2E coverage can be slow, but a balanced strategy, focusing E2E on key user flows and using faster integration or unit tests elsewhere, keeps feedback loops quick and efficient.
Why End-to-End tests alone aren’t enough
E2E tests are fantastic, they simulate real user behavior and verify that everything works together. But relying only on E2E tests is like checking if your car drives without ever opening the hood.
Here’s why that’s risky:
- E2E tests are heavy and slow: They take longer to run and are more brittle because they depend on the full stack being up and stable.
- When they fail, it’s hard to know why: A single failing E2E might mean a backend bug, a frontend change... Debugging takes longer than if you had smaller, faster integration or unit tests.
- You lose granularity: Without lower-level tests, you can’t easily isolate where a bug originates.
- They don’t scale well: Large teams need fast feedback loops. Having only E2E tests means waiting minutes (or hours) for CI runs instead of seconds for unit tests.
Conclussions
Convincing someone to write tests isn’t about dogma: it’s about pragmatism. It’s insurance against chaos. Start small, show quick wins, and let the results speak for themselves. Before long, your once-skeptical teammate will be willing to create more tests.
Top comments (0)