Feature: Support Kotlin/Native in MockK

[olonho]

For multiplatform projects it would be really nice if MockK would support Kotlin/Native as well. If some missing functionality on K/N side is needed, please let us know, and we will add it.

[oleksiyp]

I wonder how that can be done technically.

Does KN support any kind of instrumentation?

We need at least somehow inject a check of boolean in each method that defines if the function should be intercepted or something alike. This would be compile-time instrumentation/compiler plugin, of course, the runtime is even better. I've heard Kotlin way is to write compiler plugins

@olonho how is it done?

[olonho]

Runtime instrumentation is indeed likely out of the question. Unless we will do something like https://en.wikipedia.org/wiki/DTrace with lightweight probes.

Compile-time wise, there are options. Most obvious one is a source transformation, but it isn't really nice. Another one is to implement compiler plugins API, and do something like https://github.com/JetBrains/kotlin-native/blob/master/backend.native/compiler/ir/backend.native/src/org/jetbrains/kotlin/backend/konan/lower/TestProcessor.kt on IR.

I think plugin compiler API is most sensible option, we can try to implement an extension point which runs an additional pass, if certain plugin is available. Do you find acceptable option to implement simple IR transformer?

[oleksiyp]

Yes, IR transformer seems to be the way to go.

One more possible solution is to dynamically intercept functions after code generation i.e. embedding some assembly code on the fly by using additional information that compiler provides and dispatching only needed functions. But this seems to be hard. (I believe it is similar to DTrace, just another level)

Many details and design decision to be discussed if IR transformer is selected.

I'll sketch just a few:

• mocking can be done to any class in runtime. should we instrument all functions? what can be done better?
• need instrumentation that can call original functions and return result instead of it. how to do that?
• how to achieve minimum performance impact?
• should compiler build transformed version only for testing? is there such possibility?
• should be supported other mocking frameworks? sooner or later such interference may appear.

[oleksiyp]

In general, I can admit that most of the functions of mockk itself are transferred to common modules. Besides implementing the interface for function interception there are no hard tasks to perform for porting it to any platform.

Additionally, I struggle with following problems:

• JS support is experimental because it works quite badly with default parameters which are not supported by JS Proxy class. It would be nice to have solution for multiplatform mocking at the end.
• some things users would like to have extra, alike mocking inline functions
• Ideally I would like to fully support Kotlin for all platforms(Java, JS, Native, Android device testing) and possible features without any Java agents or Proxies, just via the processor, and only for legacy use additional Java agents and Proxies.

[olonho]

mocking can be done to any class in runtime. should we instrument all functions? what can be done better?
Probably, for Native we could compile with a special option, and insert call to some uniform listener with callee information. Then, actual behavior can be overiden in the runtime (slow, but will work).
Another option is limit mockability scope to only those classes seen by the compiler.

need instrumentation that can call original functions and return result instead of it. how to do that?

This shall be straightforward (as in test runner above) - you can create arbitrary complex IR instead of the original function.

how to achieve minimum performance impact?

Without dtrace-like mechanisms, I presume it will slow down execution anyway, but smartness may come from the way of calling mocked function (smth like dynamic table of invocation targets, where either original implementations lie, or we could replace it with custom pointer when mocking).

With that design, when compiled with the dynamic targets table, we could create following additional structures:

• map of function name to an index in tables below (i.e. list of (const char*, index) pairs) - name table (NT)
• original function pointers table (OFP)
• actual function pointers table (AFP)

On call site of every function we call indirectly via the actual function table. Mockers can just modify this table, using elements of the original table to figure out where to call if need original implementation. This would kill performance (every call is indirect, and no inlining), but could allow rather flexible mocking without too deep integration into compiler. WDYT?

[oleksiyp]

Performance is a difficult thing to reason as many things might be optimized on CPU level e.t.c. Without performance testing and optimization I don't think we can prove anything here in discussion.

Dynamic tables is kind of classics but require I believe more compiler/runtime rewrite.

Better do just interception via similar approach i.e. have a table that is checked at the beginning of every function and if it is filled-in then special call to mocking framework is performed:

• call sites don't need to know anything about it
• can be implemented at a higher level IR (in case you have such). best IMHO if such approch would be portable between platforms.
• as dynamic call can be two level: class lookup and then function. good performance because do just one check at the begning and table of classes can be cached, this assumes most classes are not mocked.
• can support mocking inline functions
• it should translate to few additional asm instructions with guaranteed branch prediction if done carefully. (hope so)

[oleksiyp]

Although one thing that is better with dynamic dispatch is that it allows calling original methods, which is required by spies. See no way now to do it with interceptors without overcomplication of it.

[oleksiyp]

@olonho I have following error here:

* Where:
Build file '/home/oleksiyp/workspace/mockk/dsl/native/build.gradle' line: 24

* What went wrong:
A problem occurred evaluating project ':mockk-dsl-native'.
> tried to access method org.jetbrains.kotlin.gradle.plugin.KotlinPlatformImplementationPluginBase$Companion.whenEvaluated(Lorg/gradle/api/Project;Lkotlin/jvm/functions/Function1;)V from class org.jetbrains.kotlin.gradle.plugin.KotlinNativePlatformPlugin

idea.log

[olonho]

We're looking on this issue.

[oleksiyp]

@olonho I use following kotlin plugin:

buildscript {
    ext.kotlin_version = '1.2.21'
    repositories {
        mavenCentral()
        jcenter()
    }
    dependencies {
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}

[minamoto79]

workaround for you issue could be following:

• switch to kotlin-plugin 1.2.20 (because kotlin-native plugin depends on this version)
• add kotlin-native plugin dependency to main build.gradle

[oleksiyp]

Thanks. Will try this evening