In a machine-drafted end-to-end case, how do you tell an outcome assertion from one that restates the steps just performed?
answer
- Ask who produced the value compared
- Echoes of the case's own input
- A step already watched is not evidence
- Remove the behaviour: would it still pass?
basics
~20 sAn outcome assertion checks a fact the system decided or stored on its own. A restating assertion only re-reads what the case supplied or already watched happen. Ask whether it would still pass with the behaviour removed.
solid answer
~50 sA drafting model works from what it can observe — a recorded walkthrough or the implementation — so it tends to write assertions that mirror the steps rather than the effect. The tells are consistent: the assertion compares a field against the value the case itself typed, it confirms an intermediate step that has already run, or it re-reads the very element the case just acted on. The check that settles it is a thought experiment: if the behaviour under test were removed and the system did nothing, would this assertion still hold? If yes, it is restating. A real outcome assertion names something the system decided or persisted — an order reaching a settled status, a balance moving by the amount the inputs imply — and reads it back through a path independent of the one that produced it.
code
pseudocode · 14 lines# drafted case, as generated from a recorded walkthrough
open checkout
type "AB1 2CD" into postcode_field
press "Pay"
assert postcode_field.value == "AB1 2CD" # echoes what the case typed
assert progress_indicator_was_shown == true # a step it just watched
assert confirmation_panel.visible # the page it just navigated to
# same case, asserting an outcome
order_id = place_order(cart, card_details)
stored = read_order_record(order_id) # independent read path
expected = sum(line.price * line.qty for line in cart) + delivery_fee(cart)
assert stored.status == "SETTLED"
assert stored.total == expected # derived, not copiedgo deeper
Be ready to say what an assertion is for: it checks something the system produced, not something you supplied. If the value being compared came out of your own test steps, the check proves nothing about the feature.
An interviewer expects the mechanics. Name the tells — the echoed input, the step already watched, the read through the same path that wrote it — and give the removal test as the discriminator. Then show the repair: derive the expected value, read it back independently.
Demonstrate the judgement of someone who has merged these. Explain what a pack full of restating assertions does to trust over a few releases, how you triage which drafted assertions to keep, and why a case with three sharp assertions beats one with twelve.
Own the standard rather than the individual review. Decide what a drafted case must assert before it can enter the pack, who enforces it when drafting throughput outruns review capacity, and how you keep that bar from decaying into a rubber stamp.
## What the draft actually saw A drafting model produces a case from whatever it was handed: a recorded walkthrough, a captured sequence of requests, or the code that implements the feature. None of those describe the **effect** the feature is supposed to have. They describe the **steps**. So the most common defect in a machine-drafted end-to-end or service case is not a wrong assertion — it is an assertion that faithfully mirrors the trace it was drafted from and therefore proves nothing about the running system. This bites harder at the end-to-end and service level than anywhere else, because these cases are expensive. A case that drives a deployed system for ninety seconds and then checks something it already knew is the worst trade in the pack: full runtime, no signal. ## The four tells Read every assertion in the draft and ask one question: **who produced the value being compared?** - **The echo.** The case supplies a value and then asserts the value is present — a postcode typed into a form and read back out of that same form, a request field reflected in the response because the service copies it straight through. - **The step already watched.** The case acts and then asserts the act happened: an indicator appeared, a page changed, a request was sent. Those are progress markers, not outcomes. - **The self-fulfilling read.** The assertion reads through exactly the path that produced the value, so any echo, cache or in-memory shortcut on that path satisfies it without the system ever deciding anything. - **The pinned snapshot.** The expected value was recorded from whatever the system happened to do on the day the draft was made, rather than derived from the rule the case claims to protect. It breaks on the first legitimate change and gets "fixed" by re-recording. ## The removal test There is one check that settles the argument, and it costs nothing to apply while reading: 1. Name the behaviour the case claims to prove, in one sentence. If you cannot, the case has no claim and the assertions cannot be judged at all. 2. Imagine that behaviour removed — the calculation never runs, the record is never written, the downstream effect never happens. 3. Walk the assertions one at a time. If every one of them would still hold, the case restates; it does not assert. 4. If exactly the assertions that matter would break, the case has a real outcome. Note which ones did **not** break — those are the lines to question. ## Restating versus asserting, side by side | Aspect | Restating assertion | Outcome assertion | | --- | --- | --- | | Who produced the value | The case itself, or a step it just ran | A decision or write the system made | | Read path | The same path that produced it | A path independent of the one under test | | Survives the feature being removed | Yes | No | | Survives a legitimate rework of the flow | Often no — it is pinned to the shape | Yes — it is pinned to the effect | | What a failure tells you | A step changed | The behaviour is wrong | ## What to write back into the case Replacing a restating assertion is usually a small edit, and it is the review comment worth leaving: - **Name the decided fact.** An order reaching a settled status, a balance moving by the amount the inputs imply, a record appearing with a computed identifier, an entitlement granted or refused. - **Read it back independently.** If the case created the effect by driving the screens, confirm it where a different consumer would see it — the stored record, or a read the product exposes for other purposes. - **Derive the expected value, never copy it.** Compute the expected total from the inputs the case chose, rather than pasting the number the system produced during the drafting session. - **Keep progress markers as waits, not as assertions.** An indicator disappearing is a fine thing to wait on and a poor thing to assert. ## Why this is a review skill rather than an authoring style A restating assertion is easy to see in a diff and nearly invisible once merged. It passes, it stays green release after release, and it quietly stops protecting the behaviour it was named after — the pack looks the same whether the feature works or not. When a real regression finally arrives, the case that was supposed to catch it says nothing, and the team's trust in the whole pack drops by far more than one case's worth. The review comment that fixes it is short — *"this asserts the value we typed; assert the settled total read back from the stored record"* — and it pays forward, because the corrected case becomes the shape the next reviewer, and the next drafting run, pattern-match against.
- A drafted case asserts that a confirmation banner appeared. When is that a real outcome and when is it not?It is an outcome only when the banner carries a fact the system decided — a reference the system generated, a total it computed — and the case asserts that fact. A banner that merely proves the flow reached its last screen is a progress marker: the screen can render for a request that was never accepted downstream. Assert the decided fact, and treat the banner's appearance as the wait that precedes it.
- How do you prove an assertion is not simply reading back the value the case supplied?Change the input and see whether the expectation follows on its own. If the expected value is derived from the inputs the case chose, a different input produces a different expectation and the case still passes. If the expectation is a copied constant, the case fails, and you have found the copy. The other half is the read path: verify the effect somewhere other than where the case wrote it.
- The drafted case has twelve assertions and three of them are real outcomes. Do you keep the other nine?Keep only the ones that would break if the behaviour were removed, plus any that guard a precondition the case genuinely depends on. The rest are noise: they add failure modes with no detection value, and each one is a reason the case will be edited for the wrong reason later. Fewer, sharper assertions make the case's claim readable from the case itself.
A receipt and a photograph of yourself at the till are not the same evidence: one shows the shop charged you, the other only shows you were standing there.
saying these in an interview costs you the question
- Treats a passing run as proof the assertions are meaningful
- Accepts an assertion that echoes the value the case typed in
- Counts any visible confirmation on screen as an outcome
- Believes more assertions in the draft means stronger detection
- Updates the expected value to match whatever the run produced