-
Notifications
You must be signed in to change notification settings - Fork 54
Open
Labels
FeatureFeature request issue typeFeature request issue typeS: untriagedStatus: issue reported but unprocessedStatus: issue reported but unprocessed
Description
Proposed API
Excluding untestable types from coverage should be an automatic configuration option, not a manual burden on the developer.
kover {
excludeDataClasses = true
excludeInterfaces = true
}The Problem
Coverage reports are currently cluttered with structural types that have little to no testable logic:
- Data classes are mostly compiler-generated bytecode (
equals,hashCode,toString,copy) - Interfaces are pure contracts without implementation
Why Annotations Aren't the Solution
Using @ExcludeFromCoverage has several drawbacks:
- Wrong place: Coverage settings belong in the build configuration, not the source code
- Unscalable: Manually annotating hundreds of DTOs is tedious, error-prone toil
- Silent decay: New classes degrade coverage metrics by default until a developer remembers to tag them
Feasibility
Since Kover is Kotlin-native, it can detect these types via @kotlin.Metadata or bytecode signatures reliably.
Unboxed6225 and achen3atlassian
Metadata
Metadata
Assignees
Labels
FeatureFeature request issue typeFeature request issue typeS: untriagedStatus: issue reported but unprocessedStatus: issue reported but unprocessed