Vararg Matching

## What a vararg parameter is at the call site In Kotlin, `fun log(vararg parts: String)` accepts any number of `String` arguments; the compiler collects them into an array for the callee. Inside MockK's `every { }` / `verify { }` blocks you are not calling the method for real — you are *recording* what the arguments should look like. The recording is positional and element-wise: each expression you write in the vararg position contributes one element matcher. That is why `every { log.log(any()) }` is not "match any call to log". It is "match a call whose vararg carried exactly one element, and that element can be anything". A production call `log.log("a", "b", "c")` carries three elements, so it does not match the recorded stub. ## The symptom On a strict mock, the unmatched call fails at run time with MockK's "no answer found for" message naming the mock and the invocation. On a relaxed mock or one created with `relaxUnitFun = true`, the call quietly takes the default behaviour, so the mismatch shows up later as a `verify` that fails or a stub that never fires — which is the more confusing case. If a vararg stub "just doesn't take effect", element count is the first thing to check. ## anyVararg() `anyVararg()` is MockK's matcher for the whole vararg tail. It is spread into the call with `*`, exactly like passing an array to a vararg parameter in ordinary Kotlin: ```kotlin every { log.log(*anyVararg()) } just Runs verify { log.log(*anyVararg()) } ``` It matches zero elements, one element, or many, so it is the right default whenever the test does not care what was logged and only cares that logging happened — or, on the stubbing side, when the mock must simply accept every shape of call. ## Mixed signatures Fixed parameters that precede the vararg behave normally: `fun log(level: Level, vararg parts: String)` is stubbed as `every { log.log(any(), *anyVararg()) }`. The vararg matcher only ever stands for the vararg tail; it does not swallow the preceding parameters. ## When you want to say more than "anything" `anyVararg()` is the blunt instrument. MockK also gives you predicate matchers over the elements — `varargAll { }` requires every covered element to satisfy a condition, `varargAny { }` requires at least one — and you can write literal elements before a spread matcher to pin specific positions. Reach for those when the assertion is about *what* was passed; reach for `anyVararg()` when it is about *whether* the call happened. ## Practical guidance - Stubbing a logger, metrics recorder, or any "fire and forget" vararg collaborator: `*anyVararg()`, or create the mock relaxed and skip the stub entirely. - Verifying a specific call: write the literal elements you expect, which reads better than a predicate — MockK matches them element-wise. - Debugging a vararg stub that does not fire: count the elements in the recorded stub versus the real call before suspecting anything more exotic. It is almost always the count. - Remember the same rules apply in `verify`: a `verify { log.log(any()) }` that "proves" logging happened is really asserting a single-element call, which may pass for the wrong reason or fail for a trivial one.