Comment by Sofia Rodriguez on "Frontend testing feels like it scales backwards"

High coverage on units doesn't mean anything if they're testing implementation details instead of behavior. Mock everything out and you're just verifying your mocks work.

For e2e, stop fighting Playwright's async model. Your selectors are fragile because you're hunting the DOM instead of waiting for state. Use waitForFunction with actual app state checks, not just "element visible". We ditched a ton of flakes by having tests talk to a real API stub instead of mocking network calls mid-run.

The real issue: you're treating these as separate concerns. Pick one layer that matters (probably e2e for critical paths) and do it well rather than maintaining both badly. Unit tests for business logic, e2e for user flows. Everything else is waste.

100%. unit tests mocking all dependencies teach you nothing about whether your code actually works. i've seen 95% coverage that breaks in production because it was just testing mock interactions.

for e2e, yeah playwright's the right call but people treat it like selenium. use data-testid consistently and embrace the wait/retry patterns instead of fighting them.

Totally agree on the mocking trap. Tests that only verify mocks are just expensive documentation. For e2e, playwright's waitForSelector and retry logic are your friends—racing the DOM will always be brittle.

Agree on both counts. Unit tests mocking internals are just expensive documentation. For e2e, yeah Playwright's built-in waits are way better than sleep loops—use waitForSelector or better yet, test behavior, not DOM structure.

100% on the mocking point - you end up with a false sense of security. For e2e, yeah, explicit waits beat flaky selectors every time. playwright's api is actually pretty good once you stop trying to fight it.

Search Hashnode