In a test that drives the application's screens, which steps belong on the screen and which should be arranged another way?
answer
- Three parts, only one needs a screen
- Count the reasons this case can fail
- Preconditions are more than data
- Start the case near the behaviour
- Cover the creation path once
basics
~20 sDrive the screen only for the behaviour the case is about. Everything before that - accounts, records, settings, a starting state - should be arranged through a faster channel, so the case checks one thing and fails for one reason.
solid answer
~50 sA screen-driven case has three parts: arrange the world, act through the screen, assert the outcome. Only the act needs the screen, because the screen is the point of the case. The arrange part should use the fastest channel that produces a valid state - a machine interface, a direct write, or an entry point that lands the test on a prepared screen - and the case should start as close to the behaviour as it can. That keeps the run short, but the real payoff is diagnosis: if setup is twelve screen steps, a failure anywhere in them tells you nothing about the behaviour under test. Two caveats. The state you build off-screen must be one the product could really produce, or you are testing an impossible world. And because nothing else exercises the creation path, cover it once through the screen as its own case.
code
pseudocode · 9 lines// arrange off-screen, act on the screen, assert once
rider = arrangeRider(concession: "senior")
openFarePlannerAs(rider)
selectOrigin(zone: 2)
selectDestination(zone: 5)
selectDeparture("08:12")
assert displayedFare == "3.40"go deeper
Be ready to name the three parts of a case and say which of them needs the screen. Interviewers mostly want to hear that setup does not have to be clicked through, and that a shorter case fails for a clearer reason.
An interviewer expects the mechanics: which channels can arrange a precondition, how to land the case directly on the screen that owns the behaviour, and why a state built outside the product may be invalid.
Show the diagnosis argument, not just the speed one. Talk about how many reasons a case can fail, how a broken setup channel shows up differently from a broken screen, and how you keep one deliberate case over the creation path.
Own the standard: what the team's arrange channel is, who maintains it, and how you prevent it drifting into states the product cannot produce. Be ready to say what you would trade away if the fast channel did not exist yet.
### The three parts of a screen-driven case Any automated case, at any level, has the same skeleton: **arrange** a starting world, **act** on the thing under test, **assert** the outcome. What makes a screen-driven case different is that one of those channels is dramatically more expensive than the others. Driving a screen means rendering, layout, input events, network round trips and waiting for things to settle. Each step costs real time, and each step is a place where a timing or rendering problem can end the case for reasons unrelated to the behaviour you meant to check. That asymmetry produces the central rule of screen-level case design: **spend screen steps only where the screen is the point.** The behaviour under test - the click, the typed value, the submitted form and the result it produces - runs through the screen because that is what you are checking. Everything else is a precondition, and a precondition wants the cheapest channel that can produce it honestly. ### One reason to fail Speed is the argument people reach for first, but diagnosis is the stronger one. Suppose a case about peak-hour pricing on a public-transport fare calculator opens the home screen, registers a rider, confirms an address, opens the wallet, adds a concession card, navigates to the journey planner, picks two zones, and only then chooses a peak departure time and checks the fare. That is nine screen steps of which one is the behaviour. When the run goes red at step 4, the report says a card form did not appear. Does peak pricing work? Nobody knows. The case has many reasons to fail and only one of them is interesting, so every failure needs a human to reproduce it before it means anything. A case whose setup is arranged off-screen has essentially one reason to fail, and a red result is information rather than a question. ### What counts as a precondition Preconditions are broader than data. They include: - **Records the case needs to exist** - a rider account, a saved journey, a concession card, a prior trip. - **Configuration** - a feature toggle, a fare table version, a service window. - **Position** - which screen the case starts on. If navigation is not the behaviour under test, start the case on the screen that owns the behaviour rather than walking there from a landing page. - **Identity state** - being signed in, in a particular role. ### What a faster channel means In practice it is whichever of these the system offers: a call to the machine interface the screen itself uses; a direct write into storage; a helper that builds a prepared state and hands the case a starting point; or a deep entry point that opens the application already in that state. The specific mechanism matters less than the two properties: it is fast, and it produces a state the product would recognise as valid. ```pseudocode // screen steps: 9, behaviour under test: 1 open(home); register(rider); confirm(address) open(wallet); addConcessionCard("senior") open(planner); pickZones(2, 5); pickTime("08:12") assert fareShown == "3.40" // screen steps: 2, behaviour under test: 1 rider = arrangeRider(concession: "senior") // off-screen, ~0.2s openPlannerAs(rider) pickZones(2, 5); pickTime("08:12") assert fareShown == "3.40" ``` ### The two honest caveats **You can build a state the product could never reach.** A direct write can create a rider holding a concession card that the real enrolment path would have rejected, or a fare table with a gap the product's own validation forbids. Then the case passes against a world that does not exist, or fails against a world nobody has to support. Prefer a channel that goes through the product's own validation, and treat a raw write into storage as the last resort rather than the default. **Something still has to prove the creation path works.** If every case arranges its rider off-screen, no case ever demonstrates that a person can actually add a concession card by hand. The answer is not to put that path back into every case; it is to cover it **once**, deliberately, as a case whose behaviour under test *is* the enrolment flow. Then the long path is covered, and the other cases stay short. ### Where interviewers push A good follow-up is: what if the setup channel breaks? Then many cases fail at once with the same setup error, which is a loud, obvious signal - very different from a screen suite failing in scattered, individual ways. A second push is about realism: if the case never walks the journey a real person walks, is it still an end-to-end test? The answer is that end-to-end refers to the depth of the stack the behaviour touches, not to the number of screens the case walks through on the way in.
- If no case builds its precondition through the screen any more, what stops the creation path from silently breaking?One dedicated case whose behaviour under test is that path. It walks the enrolment or creation journey through the screen deliberately, and it is the only case that pays for it. The rest arrange off-screen. That way the path is covered exactly once instead of being re-walked by dozens of unrelated cases that would each report the same breakage in a different, confusing place.
- What is the risk of arranging preconditions by writing directly into storage?You can create a state the product itself would refuse to produce - a missing derived field, a skipped validation, an inconsistent pair of records. The case then passes or fails against a world that cannot occur, and the result is not evidence about the real system. Prefer a channel that runs the product's own validation; keep direct writes for states no other channel can build, and review them when they start failing oddly.
- How do you decide where a case should start on screen?Start on the screen that owns the behaviour under test. If navigation itself is not what you are checking, walking from a landing page adds steps that can fail without telling you anything. Navigation deserves its own coverage, but as a case about navigation, not as an entry tax on every other case.
A driving examiner does not make you build the car first. They put you in a working car and watch the one manoeuvre they are grading.
saying these in an interview costs you the question
- Insisting every step must go through the screen to be realistic
- Treating setup speed as the only reason to arrange off-screen
- Building preconditions with raw writes that skip product validation
- Starting every case from the landing page and navigating in
- Leaving no case at all that covers the creation path
- Calling a nine-step setup fine because it usually passes