Hi everyone, I was wondering if anyone of you foun...

# multiplatform

[Simon Marquis]

Hi everyone, I was wondering if anyone of you found alternatives to the java-test-fixtures plugin for multiplatform projects.
At the moment, the plugin seems to not be compatible and solutions that I can see are:
• creating a new distinct "fixtures" module but it defeats the purpose of having a single module
• adding the fixtures code inside the common sourceSet and annotating it with TestOnly
• not using multiplatform and having two modules (jvm with test fixutres plugin, and android without)

[Carter]

I’ve been putting them in the common sourceset, with the hope that once proper fixtures are supported this will be the smallest migration to make. Most of the modules I’m working on are internal, so I don’t have to worry about the fixtures leaking into the public API as much.

[Simon Marquis]

But the main point was to expose them to other modules, so internal is not a "good" solution to my problem. 😕

[Carter]

I make them public visibility, but put them in a fixtures package to signal what the intent is.

[Carter]

One surprise use case I identified is that using the fixtures to generate my Composable previews is very convenient. This may mean that I keep my fixtures in the commonMain source directory permanently unless I come up with a better solution for this.

[Simon Marquis]

R8 probably removes them in the end, but yeah, that would be a solution.

[Carter]

If generating a JAR or APK, then it is easy to strip them out with R8 or ProGuard.

[Carter]

R8 and ProGuard are great for cleaning up your public API too, e.g. stripping or repackaging your internal stuff and giving it effectively unusable names based on your keep rules.

[Carter]

But if generating a native target, then it can be harder to remove them from the API. Since this was a multiplatform question, I assume there will be other targets where the R8/ProGuard solution won’t be viable.

[Simon Marquis]

At the moment no, there won't be other platforms, only Android. But this is mainly to abstract the Parcelable from a root module (used by thousands of other modules), and I don't want to force the "android" nature to the whole dependency graph.