A Kotlin class exposes a factory in its companion object, called as Report.of(row). How do you target that companion with MockK so the factory returns a canned Report, and what are the usual reasons such a stub appears to have no effect?

## Companion objects are object declarations A companion is an object declaration that happens to be nested in a class and to be reachable through the class name. MockK treats it exactly as it treats any other object: `mockkObject` patches that singleton in place, unstubbed members call through to real code, and `unmockkObject` restores it. Nothing about companions needs a separate mechanism. ## Naming the target All of these refer to the same instance when the class has an unnamed companion: ``` mockkObject(Report.Companion) mockkObject(Report) // bare class name as a value resolves to the companion ``` If the companion has a name — `companion object Factory { ... }` — you reference it as `Report.Factory`. The important point is that you are passing an *instance* (the companion) to `mockkObject`, not a class reference; Kotlin's resolution rules are what make the shorthand read like you are passing the class. Stubbing then uses the natural call syntax: ``` mockkObject(Report) every { Report.of(any()) } returns fixture // ... exercise ... verify { Report.of(row) } unmockkObject(Report) ``` ## Why production code is intercepted, including internal calls A call written `Report.of(row)` compiles to a call on the companion instance, and so does an unqualified `of(row)` from inside `Report`'s own members. Because the patch is on that instance, both are intercepted. This is what makes companion patching useful for legacy code where the factory is called from deep inside the class it belongs to and there is no parameter to inject through. ## The three reasons a stub "does nothing" ### 1. A different overload was called This is by far the most common, and it is invisible because object mocks are **spies**: an unstubbed member runs the real implementation rather than failing. Stubbing `Report.of(row: Row)` does absolutely nothing for a call to `Report.of(row: Row, strict: Boolean)`. The test then constructs a real `Report`, possibly touching a database or a clock, and either passes for the wrong reason or fails somewhere unrelated. When a companion stub seems ignored, list the overloads first. ### 2. The code calls the constructor, not the factory `Report(row)` never goes near the companion. Patching the companion has no effect on constructor invocations at all — intercepting those is a different MockK facility. If the production path you care about builds instances directly, companion patching is the wrong tool for it, and the honest options are to route construction through the factory or to use the constructor-oriented facility instead. ### 3. It is not a companion member at all A "factory" that is a top-level function in a file, or an extension function, is not a member of any object and is not reached by `mockkObject` — those are handled by MockK's static-mocking entry point. Reading the declaration rather than the call site settles this in seconds: `object`/`companion object` member, top-level `fun`, or `fun Row.toReport()` are three different things that all look identical at the call site. ## Return values are yours to build A stubbed factory has to return something. Two habits keep this clean. Return a real, fully-constructed domain object when the type is cheap to build — the test then exercises real behaviour downstream and the assertions read naturally. Return `mockk<Report>()` when the produced object is itself a heavy collaborator whose interactions you want to verify. Returning a relaxed mock is convenient but hides missing expectations, so prefer it only when the produced object is genuinely incidental. ## Scope and cleanup The patch applies to the loaded class in the JVM for as long as it is active, so it is visible to every test running in that process, not just yours. Keep the window narrow: unmock in the same test, either with `unmockkObject` in a `finally`/teardown or by using the block-scoped form `mockkObject(Report) { ... }`, which unmocks on exit. A companion left patched is particularly nasty because the symptom in the *next* test is a factory quietly returning a fixture belonging to somebody else's scenario. ## Quick checklist Target the companion instance; stub every overload the code can reach; confirm the call site is a companion member rather than a constructor or a top-level function; decide deliberately whether the factory returns a real object or a mock; and keep the patched window as short as the test.