When the generative step inside a feature returns nothing usable, what must the test case assert the user can still do?
answer
- Three shapes, and the worst is silence
- Manual route, queued promise, honest stop
- Assert the alternative actually works
- A promise needs a delivery to assert
- Typed input must survive the failure
basics
~20 sAssert one of three outcomes and assert it works: a manual route the person can finish themselves, a queued promise that really arrives later, or an honest stop. A dead end that merely looks handled is a defect.
solid answer
~40 sThere are three honest shapes, and the case has to say which one this feature promises. A **manual route** hands the work back: assert the alternative control is present, actually functional, and that anything already typed survives. A **queued promise** accepts the work now and delivers later: assert a durable work item exists, the person is told clearly, and the later delivery genuinely happens — a promise with nothing draining the queue is the most flattering of the three because it screenshots well. An **honest stop** admits the feature cannot help right now: assert a specific message and that the surrounding page still works. What fails all three is a screen that waits forever, or a fallback message sitting beside a disabled control.
code
pseudocode · 17 linesGIVEN the generative step yields nothing usable
case manual_route:
assert fallback panel names what failed
assert the manual editor opens and accepts input
assert text entered before the failure is still present
case queued_promise:
assert a durable work item exists carrying the input
assert the person is told a result will arrive later
assert draining the queue delivers that result to them
case honest_stop:
assert the notice is specific, not a generic apology
assert the rest of the page remains usable
fail the case if: an indefinite waiting indicator with no outcomego deeper
Recall the three honest outcomes — a manual route, a queued promise, or an honest stop — and that a screen which waits forever is none of them. Naming what the person can do next is enough at this level.
Explain how each of the three is asserted differently, and why the presence of a control proves nothing until the case actually uses it. An interviewer expects an assertion that would fail if the fallback rendered nothing.
Demonstrate that you test the promise to its end: a durable work item, something draining it, a delivery that is received. Show how entered input is kept safe across the failure, and how you tell a degraded path from a data-loss bug.
Own which shape the product offers per feature. A queued promise costs durable storage, a delivery channel and support load; an honest stop costs trust in a paid feature. Setting that policy, and the spend behind it, is a lead's call rather than a case-by-case choice.
When the generative step inside a feature delivers nothing usable, the feature still has to do something, and there are only three honest things it can do. Naming which one this feature promises is what makes the path testable. Without that, the case ends up asserting that a red box appeared. ## The three honest shapes **A manual route.** The feature hands the work back and lets the person complete it themselves: an editor instead of a drafted paragraph, a form instead of an extracted summary, a plain search instead of a suggestion. This is usually the strongest fallback, because the task still gets done. It is also the one most often broken without anyone noticing, because the route is a control that renders only on a bad day. **A queued promise.** The feature accepts the work now and delivers later — a message when it is ready, a document that appears in a list, a notification. This is right when the work is valuable and a wait is acceptable. It is also the most flattering of the three: a confirmation message screenshots beautifully, and a queue that nothing drains produces exactly the same screenshot. **An honest stop.** The feature says plainly that it cannot do this right now, names what failed in terms the person understands, and leaves everything around it working. This is the correct answer when there is no manual route and queueing has no value. It is not a design failure. The design failure is the fourth shape, **a dead end**: a waiting indicator that never resolves, a message with no action beside it, a fallback panel next to a disabled control, or a screen that quietly loses what the person typed. Each of those looks handled in a screenshot and is not. ## What each shape asserts | Shape | The assertion that must exist | The defect it catches | | --- | --- | --- | | Manual route | The alternative opens and accepts input | A control that renders and leads nowhere | | Queued promise | A durable work item, and a delivery that arrives | A promise nothing fulfils | | Honest stop | A specific message, and the page around it still usable | A generic apology beside a frozen screen | Three rules make those assertions real. 1. **Use the alternative, do not merely find it.** A case that asserts the presence of a "write it yourself" control keeps passing for a year after that control started opening a blank screen. The case has to follow it, type into it, and confirm the task can be completed. 2. **Follow the promise to its end.** Assert that a durable work item exists carrying the person's input, let whatever drains it run, then assert the result reaches them. Stopping at the confirmation message is the single most common gap on this path, and it is invisible while the queue happens to be working. 3. **Assert positively.** "No error appeared" is satisfied by an empty screen. Assert the named message, the enabled control, the created item — something that would fail outright if the fallback rendered nothing. ## What must survive the failure The input the person already gave is theirs, and losing it turns a degraded path into a data-loss bug. Enter text, force the step to fail, assert the text is still on screen and still submittable. The same applies to partial work: if two of three sections were produced before the failure, show those two and say which one is missing, rather than discarding everything because that is simpler to code. ## Telling the person something true The message is part of what the case asserts, and it has two jobs: say what happened at the level the person cares about, and say what they can do now. "Something went wrong" does neither. "We could not draft this right now — your notes are saved, and you can write it yourself or ask again in a few minutes" does both, and it is testable: the case can assert the notes are present, the manual control works, and the retry control is enabled. ## Why this is the part reviewers skip Nothing in ordinary use produces these screens. They are not in the demo, they are not in the design review unless somebody asks for them, and no user takes that path on a good day. That is precisely why they need explicit cases with explicit assertions. The only thing standing between a fallback and quiet decay is a case that forces the failure and then looks hard at what is left on screen.
- How do you test a queued promise all the way through rather than stopping at the confirmation message?Drive the case past the acknowledgement. Assert a durable work item was written carrying the person's input, let whatever drains it run, then assert the result reaches them through the channel promised. Stopping at the confirmation is the usual gap: it passes happily for a year after nothing has drained that queue.
- What should the fallback show when part of the work completed before the generative step failed?Keep and show the part that succeeded, and say plainly which part is missing. Discarding entered material because a later stage failed turns a degraded path into a data-loss bug, and it deserves a case of its own: enter input, force the failure, assert the input is still on screen and still submittable.
- Why is "no error message appeared" a weak assertion on this path?Because it passes when the feature renders nothing at all. The assertion has to be positive and specific: a named message, an enabled alternative control, a created work item. Absence-of-error assertions are how a fallback stays green for months after it stopped rendering.
A shop that cannot take a card can hand you a paper form, take your details and call you back, or say plainly that today is not possible. What it must not do is leave you at the counter watching a light blink.
saying these in an interview costs you the question
- Asserts a fallback control exists but never follows it
- Counts an endless waiting indicator as handled
- Discards the person's typed input when the step fails
- Stops the queued-promise case at the confirmation message
- Shows a generic apology that names nothing that failed