Summary

• Fix @InjectMockKs failing to resolve dependency order when a constructor parameter is an interface (or superclass) type
• Keep the existing typeToProperty lookup as the fast path and fall back to isSubclassOf only when no exact provider is found, preserving existing performance
• Add a test for interface-based dependencies

Problem

When @InjectMockKs properties depend on an interface (or any supertype) rather than the concrete provider type, dependency-order resolution introduced in #1500 could not match them. The exact-type lookup never found the implementation, so the graph treated the dependency as absent and the consumer was initialized before its dependency.

interface InterfaceDependency
class InterfaceDependencyImpl : InterfaceDependency
class InterfaceConsumer(val dependency: InterfaceDependency)

class MyTest {
    @InjectMockKs lateinit var consumer: InterfaceConsumer        // depends on InterfaceDependency
    @InjectMockKs lateinit var implementation: InterfaceDependencyImpl
}

Here consumer's InterfaceDependency parameter never matched the InterfaceDependencyImpl provider, so the dependency edge was missing and consumer could be created without the implementation being available.

Solution

Match providers against a constructor parameter type using a subtype check instead of strict equality. To avoid a hot-path regression (subtype reflection is much more expensive than a hash lookup), probe the existing typeToProperty map first and fall back to a subtype scan over its entries only on miss.

typeToProperty[paramType]
    ?: typeToProperty.entries
        .firstOrNull { (providerType, _) -> providerType.isSubclassOf(paramType) }
        ?.value

This covers both interface implementations and class inheritance while keeping the common concrete-type case at O(1) per parameter.

Changes

• modules/mockk/src/jvmMain/kotlin/io/mockk/impl/annotations/JvmMockInitializer.kt
  • buildDependencyGraph(...):
    • Keep the existing exact-type map lookup as the fast path
    • Fall back to a subtype scan over typeToProperty.entries using KClass.isSubclassOf when no exact provider exists
• modules/mockk/src/commonTest/kotlin/io/mockk/it/InjectMocksTest.kt
  • Add interfaceDependency() — consumer depends on an interface provided by a sibling @InjectMockKs

Test

• Interface dependency resolved via implementation provider
• Existing dependency-order tests (two-level, three-level chain, diamond, circular) continue to pass

Performance impact of DependencyOrder in Mock initialization

I ran JMH benchmarks comparing initWithDependencyOrder vs initWithoutDependencyOrder across different dependency graph shapes and sizes. The nested interface test covers interface nesting up to 5 levels deep.

Focusing on the more stable and realistic case (size = 20, thrpt mode):

• independent: initWithoutDependencyOrder is ~0.8% faster than initWithDependencyOrder
• wide: initWithoutDependencyOrder is ~3.1% faster than initWithDependencyOrder
• linear: initWithoutDependencyOrder is ~5.5% faster than initWithDependencyOrder
• diamond: initWithoutDependencyOrder is ~2.5% faster than initWithDependencyOrder
• interface: initWithoutDependencyOrder is ~9.9% faster than initWithDependencyOrder
• nested interface: initWithoutDependencyOrder is ~14.6% faster than initWithDependencyOrder

Overall, initWithoutDependencyOrder again does not show overhead compared to initWithDependencyOrder. For size = 20, it is on average about 6.1% lower cost per operation. In throughput terms, applying DependencyOrder introduces about 6.7% throughput regression on average for size = 20. Existing cases show 3-5% overhead and show comparable results to previous tests. However, tests with interfaces show performance degradation of up to 14.6%. I think the figure is acceptable because we applied opt-in.

main summary

overhead summary