Mocking Kotlin Constructs

## The problem it solves Sometimes the code under test creates its collaborator itself: ```kotlin fun notify(user: User) { val client = MailClient(config) client.send(user.email, "hi") } ``` There is no seam: you cannot inject a mock, because nothing is injected. MockK's constructor mocking gives you one by instrumenting the *class* so that the objects the production code builds are wired to MockK's dispatch. ## What anyConstructed is `mockkConstructor(MailClient::class)` installs that instrumentation. From then on, any `MailClient(...)` created by any code in the JVM is a **constructed mock**. The test never holds those objects, so MockK gives you a stand-in to record against: `anyConstructed<MailClient>()`. It is best understood as *the class's shared stub table*, not as an object. When you write ```kotlin every { anyConstructed<MailClient>().send(any(), any()) } returns true ``` you are saying: for every instance of this class created while it is mocked, a `send` call with any arguments answers `true`. The same handle is used for verification, and there the pooling is what surprises people: calls made on *different* instances are recorded together. Three instances each calling `send()` once produce three recorded `send` calls against `anyConstructed<MailClient>()`, not one each on three separate mocks. ## Spy-like fallthrough Constructor mocking is an in-place transformation, the same family as MockK's object and static mocking, and it behaves the same way: a call that matches a recorded stub is answered from the stub; a call that matches nothing runs the **real implementation**. That has two practical consequences. First, you are not automatically isolated. If the class opens a socket in a method you did not stub, that method still opens the socket. To keep a constructed collaborator inert you must stub every method the code under test will call — a stub with `any()` matchers per method is the usual shape. Second, absence of a stub is not an error. There is no strict-mock complaint pointing at the method you forgot; the test simply exercises real code, and the failure (if any) surfaces somewhere less obvious. ## When interception starts and stops The transformation is bounded in time, and reasoning about that boundary avoids most confusion: - Objects constructed **before** `mockkConstructor` ran are ordinary objects. Nothing retroactively converts them. A collaborator built in a field initializer, a lazily initialised singleton, or a setup hook that ran before the mock was installed will never be a constructed mock. - Objects constructed **while** the class is mocked route through the shared handler. - After the class is unmocked, construction is normal again. This is the first thing to check when a constructor mock "does nothing": very often the instance in question predates the call. ## The granularity limitation Because the handle is per class, you cannot say "the second instance should behave differently from the first" by identity — there is no identity to speak about. Your options are: - differentiate by **method arguments** (`every { anyConstructed<MailClient>().send(eq("a@b"), any()) } returns false`), which is often enough; - differentiate by **constructor arguments** using MockK's `constructedWith`, which filters instances by how they were built; - accept aggregate assertions and verify counts across all instances. ## Reading it back When you review a test that uses this feature, three questions cover most defects: are the instances actually created after the mock is installed; does every method the code calls have a stub, or are you happy for the real one to run; and does any assertion implicitly assume a single instance when several are constructed?