What is the latest preferred way of dealing with JaCoCo and `@Serializable` classes? I see several S...

# code-coverage

[Klitos Kyriacou]

What is the latest preferred way of dealing with JaCoCo and @Serializable classes? I see several StackOverflow questions and answers that are 3+ years old, and there is a still outstanding issue 961. Has anyone solved the problem satisfactorily?

[Matthias Geisler]

You can simply exclude them in Jacoco.

[Klitos Kyriacou]

That is what I'm doing right now, but it's only a workaround. For example, if I add a member function to a serializable class, it would be nice to have it coverage-checked, but it won't be if I exclude the class.

[Matthias Geisler]

I think this is not possible...to have such an behaviour you need to tap into Jacoco I suppose. Such behaviour would require selective probing during runtime or while generating the coverage report.
However it sounds like you are combining behaviour and state which gets serialised...can you not just pull out the state in separate thing?

[Tim Oltjenbruns]

However it sounds like you are combining behaviour and state which gets serialised...can you not just pull out the state in separate thing?

This sounds desirable to me, if its an option

[Tim Oltjenbruns]

At the very least could you use an extension function? That should be checked for coverage.

[Matthias Geisler]

Good question...how Lombok does it...I believe to remember they ship around that...

[Klitos Kyriacou]

Thanks, an extension function sounds like a good idea.