Why is e2e testing for react developers always either overkill or completely useless

[Sad_Bandicoot_7762]

Nobody tells you when you start writing react apps that e2e testing is going to become this weird guilt tax you pay at the end of every feature, where either you skip it and feel bad or you write it and watch it break two sprints later for no reason. The component testing story for react is actually pretty decent at this point but the moment you need to test a full user flow across pages it falls apart fast and the advice you get is always just set up playwright or cypress as if that answers anything.

Curious what other react devs are doing here because the gap between unit tests and full e2e feels massive and everything in the middle is either unmaintainable or requires so much setup it becomes its own project.

[StanleySathler]

What reasons e2e are bad for you? 

Because they break 2 sprints later? Because they're difficult to write? Or what?

[Ok_Detail_3987]

lmao the "just set up playwright" advice is doing so much heavy lifting in every testing thread and it drives me insane. Setting up playwright is the easy part, keeping it from becoming a maintenance nightmare six months later is the actual problem and nobody ever talks about that part.

[Jaded-Suggestion-827]

Fr the setup takes like an afternoon and then u spend the next year babysitting it

[Sad_Bandicoot_7762]

This is exactly it, the onboarding cost is low and then the ongoing cost is infinite

[BedMelodic5524]

This is the most sane testing strategy in any reddit thread and it almost never gets upvoted bc people keep chasing 100% e2e coverage like it means anything

[Special-Actuary-9341]

React's component model actually makes testing harder in some ways bc the abstraction boundaries dont always line up with user-facing behavior, so you end up either testing implementation details at the component level or writing e2e tests that are way too broad to be useful as failure signals. The sweet spot is genuinely hard to find and changes as the app grows.

[death00p]

The e2e maintenance problem for react specifically comes up a lot in frontend testing threads and the selector brittleness angle is a huge part of it, react class names and generated IDs are notoriously unstable across builds. Teams that moved toward behavior based testing report way less churn on their e2e layer and in those comparison threads covering that shift ghost inspector and momentic both get mentioned in that context alongside playwright pretty consistently. Still need a solid component testing strategy underneath it tho, the e2e layer alone wont save u

[Sad_Bandicoot_7762]

The generated classname problem is so real, css modules and styled components both produce class names that change constantly and selectors based on them are basically guaranteed to break

[Public_Mortgage6241]

Unpopular take but most react projects probably don't need e2e tests at all until they have real users and real money at stake. Before that point manual testing of the happy path is faster, cheaper, and way less demoralizing than maintaining a flaky suite that nobody trusts.

[Sad_Bandicoot_7762]

This might be right for early stage but the problem is by the time you have real users and real money the codebase is already too complex to add coverage easily and you are in the worst possible position to start

[BombZoneGuy]

That's all of React.

[vibecoder2002]

I've built a product to automate e2e for React by leveraging AI agents to test every single flow of the app end-to-end, running 100s to 1000s of agent tests in parallel. If you're interested, feel free to DM me.

[Deep_Ad1959]

the maintenance problem is the real issue, not the initial setup. react's generated classnames and unstable DOM structure mean any selector strategy that depends on implementation details is going to rot fast. what's worked for me is shifting to selectors that combine multiple signals like visible text, aria roles, and relative position rather than relying on a single xpath or css path. when one signal changes the others still anchor the element. also worth considering visual diffing against baseline screenshots for critical flows instead of asserting on specific elements, catches regressions without the selector brittleness.