In the following Kover report, there are two issue...
# code-coverage
p
In the following Kover report, there are two issues: 1) why is the "$$serializer" class being reported at all, and 2) how would I test or exercise those missing 24 instructions?
My best guess for 1) is that GenreSerializer shown below references TmdbGenre.serializer() which is a file generated by the Serialization library. I seem to recall a suggestion to filter out (exclude) the $$serializer operations but this feels like a bug workaround rather than an appropriate action. If a project source set contains a custom Foo.serializer() then that exclude operation would cause Foo's serialization code to be ignored, hence the feeling that the exclude is an unclean solution. While testing the generated serializer also seems inappropriate, it is cleaner. To do that requires that I know what that code is.
s
Unfortunately, Kover analyzes already compiled nested classes without analyzing the source code, so in general it does not exclude them. Therefore, at the moment it is better to exclude all serializer classes
"*\$\$serializer"
It does not make sense to measure the coverage for a class
$$serializer
, because there may be some branches that are executed in very rare cases that are not needed by most applications - for example, sequential decoding of instances. First of all, Kover should be used to measure the coverage of the code written by the user, the automatically generated code may change depending on the compiler version, and the user does not control it in any way.
p
Unfortunately, Kover analyzes already compiled nested classes without analyzing the source code
I assume this means that Kover will never analyze source code and boyo would I like to learn this is a bad assumption. Does it make any sense to think that a compiler plugin could capture and save all "instructions" such that Kover could leverage that data to automagically exclude code that is not in the source set being covered?
101 Views