You want MockK's JUnit 5 extension to supply collaborator mocks through your test class's constructor and to build the class under test there with @InjectMockKs. What does the extension require about the order of those constructor parameters, and what happens if you get it wrong?

## Why order exists at all A JUnit 5 test class may take constructor parameters, and the framework asks each registered resolver to supply them **one parameter at a time, in declaration order**. MockKExtension exploits that: as it resolves each mock it stores it in an internal cache keyed by the parameter's type. So at any point in the constructor's parameter list, the extension knows about exactly the mocks to the left of the current position. That is fine while every parameter is an independent mock. It becomes order-sensitive the moment a parameter is not a mock but a **real object assembled from mocks** — which is what `@InjectMockKs` on a constructor parameter means, and also what `@SpyK` on a constructor parameter means, since a spy wraps a real instance. ## What the extension does for such a parameter It reflects on the parameter's type, takes a constructor of that type, and for each of that constructor's parameter types looks the value up in its cache of already-resolved mocks. Then it calls the constructor with those arguments. Two consequences fall straight out of that algorithm: 1. **A dependency resolved later is simply absent.** The lookup returns nothing for it, and construction blows up. 2. **The lookup is by type.** Two collaborators of the same type cannot be distinguished — the cache holds one entry per type, so the later one wins. Name-based disambiguation, which property-level `@InjectMockKs` can do, is not available on this path. ## The error you will actually see Get the order wrong and MockK wraps the reflective failure in a `MockKException` whose message is deliberately instructive: *"Unable to instantiate class X. Please ensure that all dependencies needed by class are defined before it in test class constructor. Already registered mocks: [...]"* — and the tail of that message lists what the cache did hold, which usually makes the missing collaborator obvious at a glance. Recognising this message and immediately thinking "parameter order" rather than "MockK is broken" is the point of the question. ## The correct shape ```kotlin @ExtendWith(MockKExtension::class) class OrderServiceTest( @MockK val repository: OrderRepository, @RelaxedMockK val auditLog: AuditLog, @InjectMockKs val service: OrderService, ) ``` Subject last, dependencies first. If the subject's own constructor takes something that is *not* a mock — a plain value like a `String` or a `Duration` — that value is not in the cache either, and this path cannot supply it; build the subject by hand instead. ## When to use this at all Constructor injection buys immutability: the mocks are `val`s, not `lateinit var`s, and the subject is fully constructed before any test runs. That reads well for a class whose subject is identical in every test. It costs flexibility. You cannot vary construction per test, you cannot stub a collaborator before the subject is built (the subject is built during resolution, though for constructor-injected collaborators that rarely matters), duplicate types are ambiguous, and multiple constructors on the subject make the choice non-obvious. The pragmatic default in most codebases stays: collaborators as `@MockK` properties, subject constructed in one line inside the test or in a `@BeforeEach`. Explicit construction is one line, immune to ordering rules, and shows the reader exactly how the subject is wired. ## Adjacent knobs, briefly Property-level `@InjectMockKs` is a different code path — it runs inside `MockKAnnotations.init` during test-instance post-processing, not through parameter resolution, and the extension can be told to resolve property injection in dependency order with `@MockKExtension.UseDependencyOrder` (or the `mockk.junit.extension.useDependencyOrder` configuration parameter). Do not confuse the two: the ordering rule described above is specific to the constructor-parameter path, and no annotation removes it, because it comes from resolving parameters left to right. ## Interview-ready summary Left-to-right resolution plus a type-keyed cache means "declare mocks before whatever consumes them". The failure is a `MockKException` telling you exactly that. And the escape hatch is always available: construct the subject explicitly and the whole ordering question disappears.