When an extension function is stubbed through MockK's mockkStatic, how does the extension's receiver take part in matching inside every/verify, and why do extensions declared inside a class or object behave differently?

## How an extension actually compiles An extension function is not a member of the receiver type; nothing is added to `String`. For a top-level declaration such as ```kotlin package com.acme fun String.shout(): String = uppercase() ``` the compiler emits a static method on the file facade with the signature `static String shout(String $this)`. The receiver becomes the first parameter. A call site `"hi".shout()` compiles to `GreetingsKt.shout("hi")`. That single fact explains almost everything about mocking extensions. ## Matching: the receiver is argument zero MockK intercepts the static method, and it records the receiver in the same list as the declared parameters. So inside a recording block the receiver is matched by the ordinary rules: - `every { any<String>().shout() } returns "X"` — matches whatever receiver the code under test uses. - `every { "hi".shout() } returns "X"` — matches only when the receiver is equal to `"hi"`; a call on `"bye"` falls through to the real implementation. - `verify { any<String>().shout() }` and `verify { "hi".shout() }` read the same way, and a captured slot can capture the receiver just as it captures a parameter. A very common surprise is a test that stubs a literal receiver and then observes real behaviour, because the code under test built a receiver that is only *equal-looking* — a different instance whose `equals` does not hold, for example. Matching on the receiver uses the same comparison MockK uses for arguments, so identity-versus-equality questions apply to it too. ## Member extensions are a different animal Declare the same extension inside a class or object: ```kotlin object Formatting { fun String.shout(): String = uppercase() } ``` Now it is a member of `Formatting`, compiled as an instance method taking the receiver as a parameter. It has two receivers conceptually (the dispatch receiver `Formatting`, the extension receiver `String`) and it lives on `Formatting`, not on any file facade. No amount of `mockkStatic("com.acme.FormattingKt")` will touch it. You mock the declaring object, and the call is then intercepted like any other member call. The same holds for an extension declared inside a normal class: you mock or spy the instance. ## Extensions on a mocked type are not intercepted by the mock This is the one that costs teams an afternoon. Suppose `User` has a top-level extension `fun User.displayName(): String`. In a test: ```kotlin val user = mockk<User>() every { user.name } returns "Ada" user.displayName() // NOT dispatched through the mock ``` `displayName()` is a static call to the facade; the mock never sees it. The real extension body runs, and whatever member calls it makes on the mock are what the mock answers. Two consequences: unstubbed members inside that body will blow up on a strict mock, and to replace the extension itself you must `mockkStatic` its facade. When people say "my mock ignores the extension function", this is nearly always what happened. ## Inline extensions cannot be mocked at all If the extension is declared `inline`, the compiler copies its body into every call site. There is no static method left to instrument at the call site, so `mockkStatic` has nothing to intercept and the real logic runs. This applies to most of the Kotlin standard library's extension functions. The diagnosis is simple: if the declaration says `inline`, stop trying to mock it and change the seam instead. ## Practical rules 1. Look at where the extension is **declared**, not where it is called: top level -> file facade + `mockkStatic`; inside a class/object -> mock that class/object. 2. Treat the receiver as argument zero when writing matchers, captures and verifications. 3. Never expect a mock of the receiver type to intercept a top-level extension on it. 4. `inline` means unmockable — accept it and inject a collaborator instead.