Code under test builds three instances of a class whose constructor you mocked with MockK, and each instance calls the same method once. What does verify(exactly = 1) { anyConstructed<T>().method() } do, and how do you assert what you meant?

## Where the surprise comes from Every other mock you use in MockK is an object: you create it, you stub it, you verify it, and counts are naturally per object. Constructor mocking breaks that intuition because the test never obtains the objects. MockK's instrumentation is installed on the class, and the stub table and the recorded-call log live with the class too. `anyConstructed<T>()` is the way to address that class-level record. So with ```kotlin users.forEach { MailClient(config).send(it.email, body) } ``` three `MailClient` objects exist, but MockK has recorded three `send` calls on **one** handler. `verify(exactly = 1)` sees 3 and fails; `verify(exactly = 3)` passes; a plain `verify { ... }` (at-least-once) passes as well. ## Choosing what to assert **Aggregate count.** `verify(exactly = 3)` states the truth, but think about what you have coupled the test to: the number of objects the implementation happens to create. If a refactor batches two users into one client, the test breaks without any behaviour changing. Aggregate counts are fine when the number is itself the requirement ("one client per message, no reuse") and a poor idea otherwise. **Argument-level assertions.** Usually the healthiest translation of "each user got a mail": ```kotlin verify(exactly = 1) { anyConstructed<MailClient>().send("ada@x", any()) } verify(exactly = 1) { anyConstructed<MailClient>().send("bob@x", any()) } ``` These say what the system must do and stay true regardless of how many client objects were built. The verification is still class-wide, but the matcher narrows it to the calls you care about. **Constructor-argument partitioning.** When instances genuinely differ by how they were constructed — a client per region, a parser per format — `constructedWith` lets you record and verify against only the instances built with matching constructor arguments, which is as close to per-instance addressing as the feature gets. ## What is simply unavailable - **Identity.** You cannot say "the second one". No handle to the objects exists on the test side, and MockK does not expose a per-instance record you can index. - **Per-instance isolation of stubs.** A stub on `anyConstructed<T>()` answers for all instances; you cannot make the first return `true` and the second `false` by position. Sequencing terminators can vary the answer across successive *calls*, but that is by call order, not by instance. - **Ordering across instances.** Ordered verification sees one merged stream, so "instance A did X before instance B did Y" is not expressible. ## Failure-message reading A count mismatch here reports the calls MockK recorded for the class. When you see a number that is an exact multiple of what you expected, the near-certain explanation is that the production code constructs more instances than the test assumed and every one of them is folded into the same record. That is a useful diagnostic in the other direction too: an unexpectedly *high* count is often the first evidence that a loop creates a collaborator per iteration. ## Design signal When a test has to reason hard about which of several internally created instances did what, the test is telling you the production code has an invisible collaborator with an unclear lifecycle. Aggregate verification is workable; needing per-instance distinctions is the point where injecting a factory — which the test *can* hold and assert against per call — becomes the cheaper design. Say that out loud in an interview: it is the difference between knowing the API and knowing when the API is the wrong tool.