Kotlinx Serialization annotation line included in the coverage report

[saurabh-somani-philips]

Describe the bug
Recently, I updated the Kover version in my KMM project from 0.8.1 to 0.8.3, and I noticed my data classes annotated with @Serializable were not fully covered. The annotation line looks yellow in the HTML report, stating it is partially covered.

I've tried excluding "*.*serializer*" from coverage report (as mentioned in some previous issue reported 1 or 2 years ago), but it didn't help.

Errors
N/A

Expected behavior
Data class should be fully covered, ignoring the @Serializable annotation line. I don't want to exclude the whole data class to solve this issue, just the annotation part. Am I doing something wrong or Kover needs to consider updating itself after Kotlin 2.0 update (I'm using v2.0.20)?

Reproducer
N/A

Reports
This is my data class in the Kover report:

This is the coverage summary:

Environment

• Kover Gradle Plugin version: 0.8.3
• Gradle version: 8.7
• Kotlin project type: Kotlin/Multiplatform
• Coverage Toolset (if customized in build script): Kover
• Other context important for this bug: Kotlin version - 2.0.20

[shanshin]

Hi,
do you have the option to exclude companions ("*\$Companion") for serializable classes from the report?
If so, does it fix your issue?

[saurabh-somani-philips]

@shanshin
I tried excluding it from the coverage report. The Companion object's coverage disappears, but main data class's 'Branch' and 'Instruction' coverage still has some coverage left. The same is reflected in our SonarQube report, so the ultimate aim is to fix the Sonar report coverage.

[johngray1965]

Similiar issue with android's @parcelize

[mgroth0]

Confirming I have this issue too with @Serializable

[kszorin]

@shanshin , we have this problem too! This is very disturbing.
We left with Jacoco to Kotlin, because it has the same problem, but Kover also had the same problem after Kotlin update to 2.0

When is it planned to be fixed?

[JKuliska-pcty]

@shanshin we're facing this issue too and as we heavily use @Parcelable it's skewing the coverage result not in our favor.
Is there an estimate when this could be fixed?

Thank you so much.

[shanshin]

@JKuliska-pcty, we are gradually switching to using the JaCoCo agent (#720), and as a result, our reports will be rewritten. At the same time, we will try to take into account the problems with synthetic, but not marked as synthetic methods.

We try to fix the existing report for @Serializable, but fixes for @Parcelable are not in the short-term plans.

[JKuliska-pcty]

@JKuliska-pcty, we are gradually switching to using the JaCoCo agent (#720), and as a result, our reports will be rewritten. At the same time, we will try to take into account the problems with synthetic, but not marked as synthetic methods.

We try to fix the existing report for @Serializable, but fixes for @Parcelable are not in the short-term plans.

Thank you for your answer. It's a pity that the @Parcelable is not on the near timeline. Do you have some recommendations on how to globally ignore that? Is that possible with some exclusion rule? I tried but couldn't find a way.

The only thing I managed was to write a test that makes the Parcelable interface part covered by wrapping and unwrapping the class as a Parcelable but that is firstly not testing the implementation of our code but of a 3rd party dependency and also the annotation I couldn't get marked as green (tested)

cc: @shanshin

[shanshin]

@JKuliska-pcty, I will study this issue next week to see if it is possible to exclude synthetic @Parcelable declarations using filters.

[JKuliska-pcty]

@JKuliska-pcty, I will study this issue next week to see if it is possible to exclude synthetic @Parcelable declarations using filters.

@shanshin any luck trying to create the filter for it or did you conclude it not being possible with the currect filter capabilities?

[shanshin]

@JKuliska-pcty, just to clarify,
do you mean classes like @Parcelize class User(val name: String): Parcelable and automatically generated classes using the kotlin-parcelize plugin?

[JKuliska-pcty]

@JKuliska-pcty, just to clarify, do you mean classes like @Parcelize class User(val name: String): Parcelable and automatically generated classes using the kotlin-parcelize plugin?

@shanshin yes exactly classes like those. Basically what @johngray1965 already described in #686 (comment) and where one can notice the lines not being considered to be covered but there's no reasonable way to cover them

[shanshin]

Unfortunately, this cannot be removed with filters, because synthetic functions are added directly to the parcelable class.

Would it be appropriate for you to exclude all parcelable classes from the reports?
This can be done if you add such a filter to the project in which the merged report is generated:

kover {
    reports {
        filters {
            excludes {
                annotatedBy("kotlinx.parcelize.Parcelize")
            }
        }
    }
}

[kszorin]

@JKuliska-pcty, we are gradually switching to using the JaCoCo agent (#720), and as a result, our reports will be rewritten. At the same time, we will try to take into account the problems with synthetic, but not marked as synthetic methods.

We try to fix the existing report for @Serializable, but fixes for @Parcelable are not in the short-term plans.

@shanshin , when you can fix report for @Serializable?

[JKuliska-pcty]

Unfortunately, this cannot be removed with filters, because synthetic functions are added directly to the parcelable class.

Would it be appropriate for you to exclude all parcelable classes from the reports? This can be done if you add such a filter to the project in which the merged report is generated:

This is not acceptable for us - we need to have the classes tested and reported, but the annotation not.

[JKuliska-pcty]

Well, if fixing this for Parcelable is not on the near future timeline, let me just try to provide a code snippet for testing the parcelable where at least the : Parcelable gets covered even tho the @Parcelable still doesn't, like following example:

It was heavily inspired by this snippet: https://gist.github.com/tomaszpolanski/92a2eada1e06e4a4c71abb298d397173#file-utils-kt

But some part of the code was giving warnings or was deprecated so I updated it to be deprecation and warning free.

Still it's just a workaround to increase the test-coverage while not testing anything useful but if you or your company is going after the numbers, then it might be at least something.

import android.annotation.SuppressLint
import android.os.Bundle
import android.os.Parcel
import android.os.Parcelable
import com.google.common.truth.Truth.assertThat
import org.junit.Assert

@Suppress("NO_REFLECTION_IN_CLASS_PATH")
public inline fun <reified R : Parcelable> R.testParcelable() {
    val bytes = marshallParcelable(this)
    val result: R = unmarshallParcelable(bytes)
    assertThat(result).isEqualTo(this)
    if(this::class.objectInstance == null) { // only check the instance is not same for cases when the R is not an object
        assertThat(result).isNotSameInstanceAs(this)
    }
}

public inline fun <reified R : Parcelable> marshallParcelable(parcelable: R): ByteArray = with(Parcel.obtain()) {
    try {
        writeBundle(Bundle().apply { putParcelable(R::class.java.name, parcelable) })
        marshall()
    } finally {
        recycle()
    }
}

@SuppressLint("NewApi")
public inline fun <reified R : Parcelable> unmarshallParcelable(bytes: ByteArray): R = with(Parcel.obtain()) {
    try {
        unmarshall(bytes, 0, bytes.size)
        setDataPosition(0)
        readBundle(R::class.java.classLoader)?.getParcelable(R::class.java.name, R::class.java) ?: run {
            Assert.fail("Parcelable can't be null")
            throw IllegalStateException("Parcelable can't be null")
        }
    } finally {
        recycle()
    }
}

Usage:

@Test
fun test_parcelable() {
    myParcelable.testParcelable()
}