A modern programming language that makes developers happier.

kotlinlang

<@U050W8K9FTM> Did you find a solution to generate in commonTest?

<@U0NQVR2M6> No, I didn't. I think the best way in current conditions is creating an independent module for unit test.

I am facing the same challenge, I used to workout this adding the target in the list of sourceSets for commonTest but now I am getting `can be a part of only one module, but is listed as a source for both `androidUnitTestDebug` and `commonTest`, please check you -Xfragment-sources options.` ( which make sense ) Does anyone knows if we will ever get ksp generation for commonTest?

<@U0NQVR2M6> <@UC15RTBHS> I got a new way to solve the problem that the compiler can't find the generated code for `commonTest`.
First of all. Before K2, we can generate code for `commonTest` , but the code is in the path of the specific source set, e.g. `macosX64Test` . We can run the test code in `commonTest` , but the IDE can't find the generated code (there would be some errors.
After K2, we can generate the code with the same way, but we can't run the test code correctly, due to the compiler can't find the generated code now.

*Solution*: We can just create a new code path, and move the code from `commonTest` into it. Then, add this path to the final source sets (like `jvmTest` , `macosTest` ), rather than the abstract source sets (like `commonTest` , `nativeTest` ). For example, add the code path `src/commonTestCode/kotlin` to `jvmTest` :

```jvmTest {
    kotlin.srcDirs("src/commonTestCode/kotlin", path)
}```
Everything works. The last thing that need to mention is don't use KSP2 now. This way doesn't work for KSP2!

You can refer to my project (<https://github.com/ctripcorp/SQLlin/tree/main/sqllin-dsl>) to find more details.

I don't have answers to your question Marco (there's an old <https://github.com/google/ksp/issues/567|issue>), but I can also share my discoveries.
I've attempted to move those generated files from a platform to commonTest (<https://github.com/kosi-libs/MocKMP/pull/80|here>), it's working but very hacky (the gradle cache can't register those changes properly, so incremental build is probably off and cache issues could appear).
I believe a more proper solution is to generate expect/actual and using a trick like generic method resolution to jump from common to platform specific (MocKMP 2 and Mockative working that way afaik). It seems to be KSP2 compatible (at least I've enabled it and didn't see any issues).

Also note that even if KSP is probably not done for that, by loading the implementation package instead of the api one, you can cast your CodeGenerator in CodeGeneratorImpl and then use `cg.sourceToOutputs.put(commonTestFile, sourceFiles)` which bypass the security implemented when generating a file the normal way with ".." in the path. I'm not recommending it but that's maybe why my hack did work with cache :shrug:

<@UC15RTBHS> I got the same problem with yours a few days ago. I think the reason is we can't add the same path to two different source sets that they have dependencies, e.g. `nativeTest`  and `macosX64Test` .