Using MockK, how would you stub an HTTP client so that the first two calls throw an IOException and the third returns a response — and what should you be careful about when reusing one exception instance across calls?

## The shape of the problem Retry and circuit-breaker code is exactly the code that most needs a test, and testing it means a collaborator that fails a bounded number of times and then works. MockK supports this directly because failures and values are the *same kind of thing* in its answer model: an answer is anything that can produce a result for an invocation, and throwing is one such result. ## Composing the sequence The stub scope offers `throws(ex)` and `throwsMany(list)` alongside `returns`/`returnsMany`, and the additional-answer scope returned by any of them offers `andThen`, `andThenMany`, `andThenThrows`, `andThenThrowsMany` and `andThenAnswer { }`. Any of these may be combined in one chain, so all of the following are legal and equivalent in effect: ```kotlin every { c.get(any()) } throws e1 andThenThrows e2 andThen ok every { c.get(any()) } throwsMany listOf(e1, e2) andThen ok every { c.get(any()) } answers { throw IOException("1") } andThenAnswer { throw IOException("2") } andThen ok ``` The sequence is one answer object holding an ordered list and a counter; each matching call consumes the next entry. ## Rule one: order the failure and the success correctly Because an exhausted sequence repeats its final entry, the placement of the success is not cosmetic: - `throws … andThen ok` — after the failure budget is spent the call succeeds forever. This is the shape you want for "retry until success". - `returns ok andThenThrows ex` — the collaborator works once and is then permanently broken. This is the shape for "degrade after first failure" or "partially failing batch". A frequent bug is writing `throws e andThen ok` to test a *three*-attempt retry and being surprised the code passes on attempt two; the chain only ever fails once. Count the failures deliberately and pair the chain with a verification of the attempt count, since the chain itself will never complain about too many calls. ## Rule two: `throws` captures an instance, not a factory `throws ex` registers a constant answer holding the `Throwable` object you passed. MockK rethrows *that object* each time the entry is used. Consequences worth knowing: - **Stack traces.** The trace was filled in where you constructed the exception — typically the test setup line — so a failure report inside the code under test points back at the test file rather than at the call site. This is normally harmless, and occasionally very confusing when you are reading logs from a test that captures and prints traces. - **Shared mutable state on the throwable.** Suppressed exceptions, `initCause`, and anything else that mutates the throwable accumulate across calls, because it is one object. Code that calls `addSuppressed` in a retry loop can end up building a chain on the shared instance, and in pathological cases (self-suppression, cause cycles) that turns into an exception thrown *while* handling the exception. - **Identity comparisons.** If the code under test collects failures and de-duplicates by identity, two "different" attempts will look like the same failure. When any of that matters, produce a fresh exception per call with an answer step: `answers { throw IOException("attempt failed") }`. The block runs at call time, so each invocation constructs a new object with a stack trace rooted at the real call site. `throwsMany listOf(IOException("1"), IOException("2"))` is the middle ground — distinct instances, but still created up front. ## Rule three: match what the production code actually catches A retry test is only meaningful if the stubbed exception type is one the code retries on. Stubbing an `IOException` against a `catch (e: HttpException)` produces a test that passes for the wrong reason (the exception escapes and the test asserts a failure that never involved the retry logic). Assert on the observable outcome — the returned result and the number of attempts — rather than merely "it didn't throw". ## Suspend collaborators All of the above holds for suspend functions recorded with `coEvery`; the sequence and the throw semantics are unchanged. When the failure itself must be produced asynchronously or after a delay, that belongs in a coroutine-aware answer block rather than in `throws`. ## Checklist - Failures and values chain together in one stub. - Last entry repeats — put the terminal behavior last on purpose. - `throws` reuses one instance: stale stack trace, shared mutation, identical identity. - Fresh-per-call failure ⇒ throw from inside an answer block. - Always pair the chain with an explicit attempt-count verification.