Feature Request: Mocking final/concrete classes without allowClassInheritance / allowConcreteClassInstantiation flags

[ArkHak]

Hi,

First of all — thank you for Mokkery. It's the only mocking library that truly works across all KMP targets including Kotlin/Native, and it fills a huge gap in the ecosystem. The compiler plugin approach is clever and the API feels natural. Really appreciate the work you've put into this.

I'd like to raise a feature request regarding the two safety flags:

• mokkery.stubs.allowClassInheritance
• mokkery.stubs.allowConcreteClassInstantiation

The problem I'm facing:
In my KMP project I have a class like this:

// this my fake class for example for mocking in Tests
class AuthInteractor(
    private val httpClientBuilder: HttpClientBuilder, // concrete class - this bad
    private val stickerMapper: StickerMapper,
    private val tokensMapper: TokensMapper
)

When I try to mock<AuthInteractor>(), Mokkery refuses to fill the constructor arguments without enabling the flags above. I fully understand why these flags exist — calling constructors or inheriting classes can trigger real side effects (network calls, DB connections, thread leaks). The safety rationale is clear and correct.

However, this creates a dilemma:

1. Enable the flags — risk executing unintended code silently during tests
2. Extract interfaces for every concrete class — massive boilerplate, especially in a large codebase where dozens of mapper/builder classes exist
3. Write manual Fakes — same boilerplate problem

The feature request:

Would it be possible to introduce a way to mock a concrete or final class purely at the method-interception level — without calling its constructor at all? The idea is similar to how MockK handles this on JVM via ByteBuddy: it intercepts method calls without instantiating the real object.

I understand that on Kotlin/Native there is no bytecode manipulation, but since Mokkery already uses a compiler plugin, it might be possible to generate a mock class at compile time that:

• Extends or wraps the target class syntactically (satisfying the type system)
• But never calls the real constructor — similar to how interface mocks work today
• Perhaps via an explicit annotation like @MockkableClass or a new dedicated API like mockConcrete<StickerMapper>()

This would allow developers to opt into "mock without constructor" behavior per class, without enabling a global flag that affects the entire project.

Expected benefit:

• No constructor side effects
• No need to extract interfaces just for testing
• No global risky flags in build.gradle.kts
• Cleaner, less boilerplate-heavy test code in KMP projects

Is something like this on the roadmap, or is there a fundamental limitation in the compiler plugin model that prevents this approach?

Thanks again for the amazing work on Mokkery — it's become an essential part of our KMP testing setup.

[lupuuss]

Hi! Thank you for opening the discussion. I investigated it a little bit and I think I see some possibilities to solve the problem.

Separate mokkery-mockable plugin, that makes the class mockable.

Compiler plugins can only alter code that is currently being compiled. Since types you want to mock are usually in the main source set, any transformation that makes them mockable has to be applied there too. Adding this to the existing Mokkery plugin isn't an option - it would require applying Mokkery to main, which would pull in the Mokkery runtime as a main dependency and change the whole setup. A separate lightweight plugin avoids all of that. It would be an explicit opt-in: you apply it only to main, annotate the classes you want to expose for mocking, and it makes them open and adds a synthetic no-arg constructor (working across all KMP targets, unlike the JVM-only kotlin-noarg). Mokkery would then see those types as instantiable or inheritable without stubbing. The trade-off is that production code carries a @Mockable annotation, a synthetic constructor, and open members. Also, it won't be possible to alter types that you don't own.

Adding a way to allow only specific types to be instantiable/overridable

It would be configurable similarly to how annotations copying is configurable - https://mokkery.dev/docs/Guides/Mocking#annotations-copying.

I suspect that the first option should solve your problem, but it needs some time to design and implement. The second option should be much easier to add, but it does not sound as a big improvement, so I'm not sure if it's worth implementing. WDYT?

[ArkHak]

Hi @lupuuss! Thanks again for the detailed analysis — both options are well-reasoned.

Option 1 is my preference, and here's why — I actually already solved a similar problem manually in my project, which makes me confident this is the right direction.

My current workaround (what I had to build myself):

I created a custom annotation module and a conditional all-open setup in the build plugin:

/**
 * Marker for the all-open plugin.
 *
 * In normal builds (assembleDebug / assembleRelease):
 *  - all-open is NOT active
 *  - the annotation is compiled but does nothing
 *  - the class stays final in bytecode
 *
 * When running tests:
 *  - all-open IS active
 *  - the compiler removes final from the class and its methods
 *  - Mokkery can create mock<MyClass>()
 */
@Target(AnnotationTarget.CLASS)
@Retention(AnnotationRetention.SOURCE) // not included in bytecode
annotation class OpenForMokkery

In the build plugin:

fun Project.enableTestsKmp() {
....
 plugin(libs.plugins.mokkery)
 ...
 if (isTestingTaskRequested()) {
    plugin(libs.plugins.allOpen)
    // Configure allOpen plugin: open ONLY classes annotated with OpenForMokkery
    extensions.configure<AllOpenExtension> {
        annotation(OPEN_FOR_MOKKERY_ANNOTATION)
    }
 }
 ....
}

private const val OPEN_FOR_MOKKERY_ANNOTATION =
    "myApp.kmpBase.foundation.annotation.OpenForMokkery"

Then annotating the class (example):

@OpenForMokkery
@Inject // (this MetroDI)
internal class AuthInteractor(
    private val repository: AuthRepository,
) { ... }

And in tests it looks like this:

internal class AuthRootComponentTest : DecomposeComponentTest() {
    private val mockAuthInteractor =
        mock<AuthInteractor>(MockMode.autoUnit)
}

This works, but it requires:

• wiring up all-open conditionally in the build logic

• maintaining a shared annotation module

• relying on a somewhat fragile isTestingTaskRequested() check
  Option 1 would fit my needs quite well if it removes this extra all-open boilerplate.

• One important design consideration I’d raise is that constructor arguments also need to be mockable. In my case, AuthInteractor receives concrete dependencies in the constructor (like AuthRepository or various mappers). When Mokkery generates the mock via a synthetic no-arg constructor, those dependencies should not trigger real constructors anywhere in the chain. Ideally, any concrete constructor dependencies participating in the graph would also be annotated with @mockable (or be interfaces/abstract), so the whole dependency tree can be safely mocked.

My “ideal world” version of Option 1 would be:

• a @mockable or @OpenForMokkery annotation in a zero-runtime artifact (e.g. mokkery-mockable-annotations)
• a lightweight plugin applied to commonMain only
• it generates open members plus a synthetic no-arg constructor
• it plays nicely with nested constructor dependencies when they are also annotated
  Overall, it would be incredibly convenient and clean to have an official plugin from Mokkery that replaces my custom all-open wiring and removes this extra boilerplate from the project.

This would be a killer feature for Mokkery in KMP.

Thanks again for the great library and for taking the time to explore this idea — I really appreciate it. I’d be very happy to personally help test early builds and provide feedback on the API design if you decide to move forward with this.

And of course, if you come up with an even more convenient and elegant way to mock final classes, that would be amazing to see.

[lupuuss]

I've published a snapshot version with mokkery mockable plugin - 3.4.0-SNAPSHOT. To access it, you need a snapshots repository:

maven { url = uri("https://central.sonatype.com/repository/maven-snapshots/") }

You need to apply it after mokkery plugin:

plugins {
    id("dev.mokkery") version "3.4.0-SNAPSHOT"
    id("dev.mokkery.mockable") version "3.4.0-SNAPSHOT"
}

Both plugins must have the same versions.
It should work out of the box as I prepared an artifact with some default Mockable annotation. If you want to use your own, you can do that with mokkery.mockable.annotations("your.Annotation"). When the custom annotation is configured instead of the default one, artifact is not added to dependencies.

What plugin does? It's a mix of kotlin no-arg and all-open plugins. It makes the class full open and adds a constructor without side effects - none of primary constructors is called by it, so even the init blocks are not executed. The only constructor that must be called is the super constructor. Currently, to make class mockable, its super class must be Any or it also must be made mockable to keep the constructor side effect free.

Regarding the conditional setup for testing. I don't really want to add conditional wiring for the same reason you don't want it - it's fragile. In general, I would avoid this. Instead:

1. If your your classes are actually meant to be published and used by third parties, I would avoid using Mockable.
2. If your classes are just a part of some server or Android app, I would not bother with applying it conditionally. Generated constructor is not visible, so the only problem is the class being unnecessarily opened and someone in the codebase might inherit from it. This also can be addressed - you can create a custom Mockable annotation with SubclassOptInRequired. With this configuration you can get a class that Mokkery is able to inherit from, but it requires opt in when inherited from the codebase.

I would be grateful for your feedback!

[ArkHak]

Hi @lupuuss!

Thank you so much for the incredibly fast implementation! This is exactly the solution I described as the "ideal world" version — and I truly think this is the perfect approach for this problem.

I'll definitely test 3.4.0-SNAPSHOT on my project in the next few days and provide detailed feedback. I'm particularly interested in:

• How it handles dependency chains (when a class constructor takes other concrete classes also marked as @mockable)
• Compilation performance on a medium-sized KMP project
• Integration with my existing isTestingTaskRequested() approach

Great idea about SubclassOptInRequired — that's an elegant solution to prevent accidental inheritance in production code. I'll definitely try that approach.

I'm really looking forward to the full 3.4.0 release — I'm sure this solution will be appreciated by many KMP developers who face this pain on a daily basis.

And one small thing — if there's any way to give a little credit for raising this issue, I'd really appreciate it 😊

I'll report back after testing!