@Arkadii Ivanov Snapshot testing is all well and good, and I agree that your composables should be as stateless as possible (and properly layered when state is needed to have a stateless version). But it still gets the same code coverage as writing a test with a compose rule. The only difference is your assertion is essentially comparing the results of the stored image with the one generated from the current code. It doesn’t solve the issue of coverage %. I also would definitely NOT want to completely exclude composable code (vi file and class patterns) from sonar because it encourages people to NOT write tests since they won’t fail whatever quality gate you do have in place.

This boils down to the fact that you either have to do one of 3 things from what i can tell: • Lower your quality gate • Exclude an entire module from sonar • Exclude specific files/classes Architecture things, like stateless composables, and testing strategy like snapshot testing will not help at all with this problem.

(and i agree with all those things you both mentioned, to be clear)

You can also simulate UI interactions and verify Composable outputs.

I've been doing something like this, just a sample: https://github.com/arkivanov/Decompose/blob/master/sample/shared/compose/src/jvmTest/kotlin/com/arkivanov/sample/shared/counters/counter/CounterContentTest.kt