In Android development with Jetpack Compose, we often use the @Preview annotation under our composable components so that Android Studio can render UI previews.
However, these @Preview functions are not part of production code and should not be tested. The problem is that @Preview annotated functions are required to be in the same file as the actual component, so they end up being included in coverage calculations. This leads to misleading coverage numbers and unnecessary frustration for teams.
Right now, we don’t see a way to tell Sonar to exclude only the @Preview annotated functions while still keeping the rest of the file in coverage.
It would be extremely helpful if Sonar could provide a way to:
Exclude functions by annotation (e.g., ignore all methods annotated with @Preview)
Or provide a clean configuration option specific to Android Compose previews
This would let us keep meaningful coverage metrics without artificially lowering them due to functions that are never meant to be executed in tests.
At our company, this has become a real pain point, and I imagine many other Android teams working with Compose face the same issue. I strongly suggest adding support for this feature.
SonarQube just reads the JaCoCo report – so I think you’re really looking for “how can I exclude @Preview functions from JaCoCo coverage”, at which point SonarQube will listen.
Thanks for the reply.
As my observation, Sonar does not just read the JaCoCo report and display it. Instead, Sonar takes JaCoCo’s report and compares it against its own codebase. If JaCoCo says that a class is covered, Sonar marks it as covered.
However, if you exclude files in JaCoCo (since JaCoCo allows that), Sonar will not exclude those files. Instead, it will still list them and mark them as uncovered. This is because Sonar has its own exclusion mechanism, separate from JaCoCo.
So we can’t rely on JaCoCo’s exclusions to solve this problem; it has to be handled on the Sonar side.
I understand that we can ignore an entire file, but the whole point here is that we only need to ignore part of the file. Specifically, we need a way to ignore certain functions (e.g., those annotated with @Preview).
This can’t be solved through JaCoCo exclusions, because Sonar does not apply JaCoCo’s exclusions directly. What we really need is the ability in Sonar to exclude only specific functions or annotated methods, not the whole file.
One suggestion was to use an annotation-based approach, and that would definitely work, but honestly any mechanism that lets us ignore just part of a file would solve the problem.
Sonar does apply JaCoCo exclusions entirely, it’s just that if a file does not exist at all in the JaCoCo report, SonarQube will assume there’s 0 coverage and try to calculate how many lines are executable. I assumed that’s what you’re referring to here:
If JaCoCo reports coverage on a file, SonarQube will listen 100% to JaCoCo about which lines can be covered by tests and which can’t.
Ah, now I see what you’re saying. If there is a JaCoCo report for a file, Sonar relies entirely on JaCoCo’s data. It doesn’t calculate line coverage itself—it just trusts JaCoCo’s report and uses that information directly.