Kover/Serialization bug in 1.9.10? I upgraded a pr...

# serialization

[pajatopmr]

Kover/Serialization bug in 1.9.10?
I upgraded a project from 1.8.10 to 1.9.10 without changing any code. Much to my surprise (and chagrin), Kover complained that instructions in a serializable data class containing a list property were not covered. I have filed an issue with Kover (#460) but my best guess is that Kotlin serialization is causing the problem and that it is related to Issue 2331. The Kover report follows. Is this a known problem? Any suggestions on what new thing in 1.9.10 serialization might be the cause or what might cure the problem?

[pdvrieze]

It would be necessary to have a look at the actual detailed coverage of the bytecode. (As well as how it is generated - whether it is marked as synthetic etc.).

Assuming that your tests do actually test serialization/deserialization I suspect that the tests don't test all cases or there are some bridge methods not triggered.

I notice that you exclude serializers from coverage, this may be hiding an underlying limitation in your tests.

[pdvrieze]

Did a bit of testing (adding serialization invocation). It still doesn't fix the "instruction coverage"

[pajatopmr]

@pdvrieze Thanks for applying some effort to this issue. Your initial points are well taken. Would that I could get rid of all excludes. There is an issue about the *serializer exclude, #130 in Kover I seem to recall.
I'd love to see your additional tests.
This code is intentionally simplified to make it easier for the Kover/Serialization devs to get to a helpful conclusion. In the real project I generated a lot of additional tests but never got to 100%. I used the decompiled byte code to lead me in generating tests but it was heavy slogging trying to decipher the generated code.

[pdvrieze]

@pajatopmr The holdup is that there is no way to determine which instructions were covered, and which not, thus making it hard to know what is exactly going on/which bits of code are not covered. If Kover allows instruction level measuring it should provide reporting at that level. Having said that

The test I added is:

@Test fun `serialize and deserialize`() {
        val json = Json {  }
        assertEquals("{\"data\":[\"a\",\"b\"]}", json.encodeToString(Common(listOf("a", "b"))))
        assertEquals(Common(listOf("a", "b")), json.decodeFromString<Common>("{\"data\":[\"a\",\"b\"]}"))
    }

It's probably better to split them out, but this was just trying to see a difference (It increased the pass count for the annotation line from 2 to 3).

[pajatopmr]

This last post is similar to what I usually do with serializable testing. Thanks for posting.