Open dalewking opened 4 years ago
This year KMP becomes stable. Is this on the roadmap?
Looking at KMP, it seems to be for the Android projects. @koral-- Maybe it would better fit your Android fork of GPP?
What do you mean with Android projects? Android is one of the multiple targets KMP has
What do you mean with Android projects? Android is one of the multiple targets KMP has
I mean, this project (szpak/gradle-pitest-plugin
) is for regular Java projects (no mobile). The Android projects (and things related to the Android Gradle plugin) are covered by the fork (koral--/gradle-pitest-plugin
). As Android is one of the target, it (most likely - I don't know the project internals) will not work with this project and I proposed the fork. I have no idea about the support for iOS part.
Kotlin Multiplatform is a technology to compile Kotlin code to multiple targets. JVM is one of them, Android is another. JS and WASM are others as well.
I personally use Kotlin/JVM for my backends and Kotlin/JS for my frontends. The Kotlin Multiplatform Gradle plugin creates different source sets for different platforms; the JVM platform is identical to any other JVM platform. Currently, I cannot use this project for my JVM code because the Kotlin Multiplatform plugin is not supported. As I am not doing mobile development, I do not believe this issue is in scope for the Android fork.
As requested here would like to have support for kotlin multiplatform mobile plugin. I have it working with a manually created gradle task and the command line version of pitest.
If you need a KMM Appication to test with you can follow these instructions.
The goal is to run pitest on the commonMain classes using the tests in commonTest using the setup for the testDebugUnitTest task.
If it would be of help here is the things I did in our project to create a pitest task in the shared project. First creating a pitest configuration (Note we use the io.spring.dependency-management plugin which is why there are no version numbers):
And the actual task:
The pureCloudApi stuff is another module in the project that is generated using openApiGenerator.
It is using 2 gradle properties with the default set in gradle.properties for controlling verbose mode and the target classes (so that you can focus on a file or package)
I have another task that inlines the css style into the report because our Jenkins requires authentication and loading the CSS file does not work, but this is probably outside the scope: