https://kotlinlang.org logo
Join Slack
Powered by
So, does anyone here use sonar and quality gates w...
# compose
m
So, does anyone here use sonar and quality gates with composable code? We’re having a nice heated discussion about our 80% quality gate and how it’s nearly impossible to meet that number when you are primarily working on composable code. Compose generates so much code that just can’t be tested, and the kover engine (either intellij or jacoco) considers that untested code and your numbers come in way low. What solution / compromise, if any, did you come up with?
a
I would try moving all logic out of Compose, and test as usual. And keep the Compose UI as stateless as possible, and test with screenshot tests.
💯 1
l
The solution my team used at my last job was to have a separate module for our UI that required 0% coverage and logic that had an agreed-upon minimum, and used integration/screenshot tests of important use cases to test the UI.
m
@Landry Norris From what i’ve seen sonar doesn’t have the ability to change quality gates based on the modules. The best you could do is to exclude an entire module from sonar by telling sonar to skip it. That’s also hard to do when you have a legacy app which started as a large monolith with a lot of UI code in the main “app” module.
@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)
l
I've always found unit tests to be more trouble than they're worth with UI. When you require 100% coverage, any small change in UI can fail a large number of tests. We were happy with defining screenshot tests for our major UI use cases, and disabling kover for the module. This does require that there's no major logic in the UI module, which can be tough for a legacy project.
m
We are set at 80%, and for a lot of our libraries (standalone repositories) we went down to 60% specifically for compose reasons. But more stuff is migrating into a mono repo that’s set to 80% and there’s pushback against changing that.
l
If you can be confident that screenshot tests cover your major use cases, I would just disable coverage for the module. No need to test twice, but I also get that removing logic isn't always feasible in legacy projects.
m
For instance we just migrated an entire feature to it’s own module in the mono repo. A member on my team submitted code. It had 90%+ coverage on the logic (vm’s etc…) and 60%ish on the composable code, with most of the missing stuff being branches that are generated by the compiler and can’t be realistically tested. So we keep having to bypass the quality gate to merge.
a
If your Composable is stateless then you can easily supply and assert all possible states. Which will give you pretty good coverage.
You can also simulate UI interactions and verify Composable outputs.
6 Views
Open in Slack
PreviousNext
Powered by