A sign-up screen limits how often its confirmation email can be re-requested; what should an automated case assert when the limit trips?

A resend limit is not a disabled button. It is a product behaviour with a user-visible contract: after some number of requests inside some window, the flow refuses, tells the user when they may ask again, and stops sending. A case that checks only the greyed-out control has tested the convenience and none of the contract. ## The four assertions When the request that exceeds the limit is made, four things must be true, and each catches a different real defect: 1. **The refusal is visible.** The user is told the request was declined. A silent no-op, where the screen behaves as though the message is on its way, is worse than an error: the user waits, asks again, then abandons the flow. 2. **The refusal is actionable.** It states when the request becomes available again, in terms the user can act on. "Too many requests" on its own converts one problem into a support ticket. 3. **Nothing extra was sent.** The number of messages in the recipient mailbox is unchanged by the refused request. The screen and the send path can disagree: a flow can display a refusal and still queue the message, or block the visible control while the request behind it keeps sending. 4. **The link already delivered still works.** A refused request issues nothing, so it has no business invalidating what the user is holding. A limit that strands the user is a denial of the whole flow wearing the costume of a rate limit. | What a weak case checks | What the contract needs | | --- | --- | | the control is disabled | the request itself is refused | | an error appeared | the error says when to retry | | the run did not crash | the message count is unchanged | | something was blocked | the delivered link is still usable | ## Recovery is half the behaviour A limit that never lifts is a lockout. The case is not finished until it proves the counter resets: advance past the window the refusal named, request once more, and assert that it succeeds and a message arrives. That one step is what turns "the product blocked me" into "the product told me the truth about when I could try again", and it is the assertion that catches a window configured in the wrong unit or a counter that never decrements. Two shapes of limit exist, and the recovery step is what tells them apart. A **fixed window** resets on a boundary, so the whole allowance returns at once. A **rolling window** ages the oldest request out continuously, so waiting exactly the stated interval restores exactly one request rather than the full allowance. A case that expects the whole allowance back is asserting the wrong model, and it will fail intermittently in a way that looks like flakiness rather than a mismatch. ## Where the threshold comes from Hard-coding the number is the standard mistake. The case then fails on the first deployment configured differently, and the fix applied under time pressure is to raise the number until it passes, which quietly deletes the assertion. - Read the threshold from the configuration the target deployment is running with, and drive the loop from that. - Assert that each request up to the threshold **succeeds** and produces exactly one message. The refusal only means something if the allowed requests genuinely worked. - Never assert a value observed in a previous run. Looping until the request fails and recording the count is a case that cannot fail; it will absorb a change from five allowed requests to fifty without a word. - Where a number has to appear in the reasoning, define it in the case itself as a scenario rather than treating it as how such limits generally behave. ## Keep the boundary clean The control under test is the **product's own** limit on the resend action. Refusals that arise further down the delivery path, where a receiving system slows or rejects a burst, are a different subject with different symptoms and a different owner, and folding them into this case produces a test that fails for reasons the product cannot fix. Tell them apart by where the refusal appears: the product's own limit is visible immediately in the response the user gets, while a downstream problem shows up as a message that was accepted and then did not arrive. The last thing worth asserting is that the limit is scoped the way the product intends, whether that is per account, per recipient address, or per originating client. A case that only ever exercises one account cannot tell you which, and a limit scoped more broadly than intended will refuse a request that a second, unrelated user made.