Your frontend test suite fakes the network in every single test, so no test ever talks to a real server. What fidelity risk have you accepted, and how would you decide where in the portfolio to pay for a real backend?
answer
- the suite agrees with itself
- green all the way down
- fakes cannot model real auth or CORS
- blast radius times rate of change
- a small band you can name
basics
~20 sYou have accepted that every response in the suite is your own belief about the API, so the whole suite can stay green while the server changes underneath it. Closing that requires a small, deliberately funded band of tests running against a real backend on the riskiest flows.
solid answer
~50 sA faked network means the suite verifies the frontend against itself: your handlers encode what you think the server returns, so the day a field is renamed or a response is paginated, nothing fails until a user finds it. Fakes also cannot reproduce real auth and cookie behavior, real redirects and CORS, real latency and ordering, or server-side validation. The judgment call is not "fakes or real" but how much real-server exposure to buy, because real-backend tests are slow, need owned environments and data, and fail for reasons outside your change. I would fund a deliberately small band — the flows where a silent break is most expensive, weighted by how often that API actually changes — and keep everything else on fast faked-network tests. Then I would treat the size of that band as a number the team defends, not one that drifts.
go deeper
Know that a test with a faked network never contacts the real API, so it cannot notice the server changing — and that something else in the pipeline has to be responsible for catching that.
Explain what a fake structurally cannot reproduce — real credential handling, cross-origin and redirect behaviour, real timing, server-side validation, real data variety — rather than just saying fidelity is lower.
Show you can place the tests: pick specific flows for real-backend coverage, justify each by blast radius, and name the operational costs you take on — environments, data, and telling a real failure from an environmental one.
Own it as a portfolio and budget decision: define how much real-server exposure the organisation buys, who runs the environment, how the band's size is defended over time, and what evidence would make you grow or shrink it.
## Name the risk precisely With the network faked everywhere, every response the suite has ever seen was written by a frontend engineer. The suite therefore proves internal consistency: the app agrees with the app's own beliefs. It cannot detect any change on the other side of the boundary. The concrete failure is silent and total. A field is renamed, a value becomes nullable, a list starts arriving paginated, an endpoint moves, an error body changes shape — the handlers still return the old thing, every test passes, and the first signal is production. The suite's green does not degrade gracefully as it becomes wrong; it stays green all the way down. There is a second, less-discussed class of gap: things a fake cannot faithfully model even in principle. - **Real credential and session behaviour** — how the server actually treats an expired or missing credential, and what the browser does with cookies it receives from a real origin. - **Real cross-origin and redirect behaviour** — a handler answers whatever you tell it to; a real origin enforces its own rules. - **Real timing and ordering** — concurrent requests, server-side race conditions, responses arriving in an order you did not imagine. - **Server-side validation and business rules** — the server rejecting input your frontend thought was fine. - **Real data variety** — the empty account, the account with 40,000 rows, the record with an unexpected null. Hand-written fixtures encode the cases you already thought of. Real systems specialise in the ones you did not. ## Why the answer is not "use real servers everywhere" The reason teams end up fully faked is that real-backend tests are genuinely expensive, and a strategy that ignores that will be abandoned: - **Speed** — orders of magnitude slower, which changes how often people run the suite and therefore how much it is worth. - **Environment ownership** — someone must run, seed, upgrade and pay for it, and that someone is usually not the frontend team. - **Failure attribution** — a red test may mean your change, a backend deploy, or a flaky environment. Tests that cry wolf get muted, and a muted test is worse than no test. - **Coupling to shared state** — parallel runs, leftover data and other teams' activity all become sources of nondeterminism. So the real design question is a portfolio one: how much fidelity to buy, where, and at what running cost. ## How to decide where to spend I would allocate real-backend coverage by expected cost of a silent break, not by feature count. 1. **Rank flows by blast radius.** Sign-in, payment, checkout, anything that loses money or locks users out. A silent break there is expensive enough to justify a slow test; a silent break in a settings toggle is not. 2. **Weight by rate of change on the other side.** An API surface that ships weekly needs a live tripwire far more than one that has not changed in a year. Ask which endpoints actually moved in the last six months. 3. **Ask what the fake structurally cannot cover.** If the risk is auth, session lifetime, redirect behaviour or server-side validation, no improvement to the handlers helps — that flow needs a real server or it needs nothing. 4. **Cap the count and defend it.** A named, small set — the flows the team can recite — beats an unbounded suite that grows until it is too slow to run and gets skipped in the pipeline. 5. **Place it where it fails early enough to matter.** A real-backend check that only runs nightly is still useful as a drift tripwire; one that gates every commit had better be fast and stable. ## The complementary move Spending on real-server tests is one half. The other half is making the fakes wrong-detectable rather than merely convenient: keeping response fixtures derived from the API's own definition rather than typed by hand, and treating a mismatch as a build failure. That work belongs alongside the portfolio decision — the two together mean the fast tests notice shape drift and the slow tests notice behaviour drift. Equally important is what you refuse to buy. Duplicating your whole faked suite against a real backend gets you a second slow suite testing the same UI logic for the third time, with worse failure messages. The real-backend band should test the things only a real backend can prove, and nothing else. ## How to answer this in an interview Start by stating the risk in one sentence — the suite verifies the frontend against its own assumptions. List what a fake structurally cannot model. Then refuse the false binary: keep the fast faked band wide because it is where refactor safety and speed live, and buy a small, explicitly justified amount of real-server exposure on the flows where silence is most expensive and the API changes most. Finish by naming the running costs you are signing up for — environments, data, attribution — because a principal-level answer owns the maintenance, not just the idea.
- How would you know whether your current real-backend band is the right size?By what actually escapes. Track production incidents whose root cause was a frontend-server mismatch and ask, for each, whether an existing slow test should have caught it or a new one would have. Add on evidence, and remove tests that have never failed for a real reason while regularly failing for environmental ones.
- Do real-backend tests belong on every commit or on a schedule?It depends on whether they are gating or detecting. A small number of critical-flow tests can gate a merge if they are fast and stable enough that a red run is believable. Broader drift detection is better on a schedule against a shared environment, where slowness is acceptable and a failure means investigate, not block.
- How do you stop a real-backend suite from becoming the flakiest thing the team owns?By keeping it small, keeping each test independent of state other tests or teams leave behind, and treating every flake as a defect with an owner rather than a retry. Also by attributing failures fast — if nobody can tell in a minute whether a red run is the app, the backend, or the environment, people stop reading it.
saying these in an interview costs you the question
- Says network fakes fully cover integration because the shapes match
- Proposes duplicating the entire suite against a real backend
- Treats every flow as equally deserving of real-server coverage
- Ignores who owns and pays for the test environment
- Adds real-backend tests but keeps auto-retrying them past flakes