I get it is early times still in the world of jetp...

# compose

[pajatopmr]

I get it is early times still in the world of jetpack compose, nevertheless I have a notion that it is not too early to raise the topic of code coverage for compose code. What would it take to get either an IntelliJ or a Jacoco coverage report for the JetNews sample app? The IntelliJ path did not look promising so I am about to explore the Gradle/Jacoco path.

[gildor]

Gradle doesn’t have own code coverage tools execpt jacoco, isn’t it?

[gildor]

If something doesn’t work by default, it makes sense to at least report it on Jacoco issue tracker

[gildor]

this how it worked for Kotlin, I think nothing was added/changed on Kotlin side, Jacoco and community contributions just fix most of issue with jacoco and default Kotlin coverage, I think it also a way for Compose, if there are issues

[pajatopmr]

Yes, I'm fairly certain Gradle only supports Jacoco and that device based testing (instrumentation tests) must use Gradle (IntelliJ coverage is only available for JVM based testing.) Compose testing, therefore, must be Gradle/Jacoco based.
My experience with Kotlin/Jacoco is that as of Jacoco version 0.8.5, it was getting better. but still not ready for prime-time. Also, it was the only game in town. That data point is probably 2 years old if not older.
I will reach out here (Kotlinlang Slack) and file bug reports/issues as they arise to Jacoco and/or Jet Brains, as appropriate.

[gildor]

but still not ready for prime-time

Why?

[gildor]

I think it worth to arise a bug against Jacoco

[streetsofboston]

@gildor My biggest issue with Jacoco and Kotlin is that Jacoco still doesn't cover inline functions.... So, I agree, not ready for prime time....

[gildor]

There is anyway no better alternative now
Also it open source after. I just wouldn't expect too much attention to this from JB, it probably has higher chance to be fixed with community contribution

[pajatopmr]

As near as I can tell, Jacoco is of less value today than it was over a year ago. My recollection is that I could work around some issues, like lateinit , but with 1.3.72 these workarounds no longer work. With IntelliJ the JetBrains code coverage tool is way better than Jacoco. I'm guessing this is the case for unit testing (off device) with Android Studio as well. btw, the preferred approach by the Jacoco devs in dealing with Kotlin is to use a filter for dealing with generated code like lateinit. This has me concerned that the Jacoco project is unlikely to treat Kotlin as a first class citizen. It might be time to give up on Jacoco and find another solution. Thoughts?

[gildor]

Not sure that this in general related to compose

[gildor]

You can try to convince Kotlin team invest time on it, but honestly I would against spending their time on it and instead let community handle this

[pajatopmr]

I'm not sure this is related to compose either but I think it is in the sense that compose generates a lot of code that is not seen by a tool like Jacoco. My initial reaction to my first Jacoco report generated for Jetnews was something like, "what is going on here?" As I started to drill into the code, like lateinit I saw results that used to be better (pre-compose). I will continue to analyze this code but, as you might imagine, it is very heavy going.
I've no intention on convincing any Kotlin team to do anything. A community solution is the only solution I foresee. I see KMP as needing code coverage for all targets, preferably a common solution. Right now there are a few sort-of solutions in the JVM space (Jacoco and IntelliJ), some in the native space (gcov and whatever LLVM uses) and I don't know what in the JS or WASM space. Long term, I don't think this works well. And I have no clue what shape a long term solution takes. For me, it is becoming an itch that I might just have to scratch sooner than later.