I have Kotlin code that is platform agnostic. It will eventually end up being mainly used on Android, but being able to run the code on the PC makes debugging a million times easier. For this reason, I keep the library platform agnostic, and would like to be able to have Kotlin/Native applications using this library on PC. These PC applications would be purely for testing and development. In parallel, I’d have a test app for Android, fulfilling the same purpose (development and testing) on Android phones.
Now I wonder about how to organize this. From what I gather from this article, it should be possible to create a common module, an Android module, and a Kotlin/Native module. I do wonder though if this plays well with Android Studio and/or IDEA.
Also, I have been considering to perhaps separate the common code further from the platform specific code, since the common, platform-agnostic code can in fact be a completely standalone project.
I’d like to hear opinions. The article describes the former approach - multiple modules, Kotlin multiplatform - but multiplatform is in its alpha state. The latter approach sounds more stable, but also more of a hassle if I update something in the common module.
That article is somewhat dated. There is a lot more information and support for multiplatform now.
Although I wonder why you would want a separate target for testing. Can you not use unit testing (i.e. jUnit or kotlin-test?)
If your only goal is easier testing, I would recommend a JVM over native. Android is essentially JVM anyways–any code that could be tested on another platform would likely be easier tested from within your Android module using unit tests.
1 Like
I am referring to manual testing. That is: I run test tools to evaluate the performance and behavior of the library. I am not talking about unit tests.
Perhaps calling these “development tools” instead of “tests” would make it clearer. One example would be a library that implements a network protocol. I would then have a command line tool that allows me to simulate a connection setup to see what packets are produced by the library.
1 Like
I see. So not simply testing the library that you would use in your android app but you want a separate set of code that supports integration testing?
Often in Gradle this is done with a separate sourcesSet for integration tests.
Even if I’m not fully understanding what you’re wanting to test, I would still recommend the JVM. If you’re wanting a separate suite of tools to support your testing, such as some network or other environment tools, I’d stick with the JVM unless there’s something very specific your want from Kotlin/Native. The reason for this is that the JVM is usually easier to develop for in conjunction with Android. And on top of that, your application tests could call your test suite tools directly for integration testing (and control the dependencies better as a sourcesSet in Gradle).
If your test tooling is totally separate, you might want to make it a totally separate module. In that case you could go with Kotlin/Native, Python, or any other language. I often have both and will run integration tests in a Docker container or VagrantVM with mixed test tooling.
1 Like