What’s up everyone? I’m in the middle of tightening up our frontend release process, and I’m trying to make our integration tests actually catch regressions without becoming a flaky time sink.
Right now we lean on “happy path” UI flows and a few network mocks, but failures keep coming from timing and state leakage between tests, and the fixes usually make the suite slower and less realistic; how do you draw the line on what to mock vs run real, and what guardrails keep the suite trustworthy over time?
1 Like
The “timing and state leakage” part usually means your tests are sharing the same browser/storage/server data, so I’d start by making every integration test run against a fresh, disposable backend state instead of trying to paper over it with waits. What’s worked for me is: keep the UI real, but make the data layer deterministic. Seed the DB (or reset via an API) per test, and intercept only truly external stuff (payments, email, analytics) while letting your own API be real. Mentally, it’s like you’re testing the app, not the internet. One question: are you running these against a shared staging env, or spinning up an isolated environment per CI run? That one choice tends to decide whether the suite ever feels trustworthy.
