You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the newbie user can be read as “default filters for all reports”.
Without reading the documentation, it is not clear what exactly the defaults block is used for.
Default reports solve too many things
Default reports both generate reports only for classes from JVM targets, and also used in Android projects to get a report on few or all of the build variants - by using mergeWith(“variantName”).
default reports behave differently for different project types
Calling the koverHtmlReport task for a JVM project leads to the generation of a report on all classes from the project.
Calling the koverHtmlReport task for a Android project leads will not generate anything until the user explicitly writes koverReport { defaults { mergeWith("release") } } .
Calling the koverHtmlReport task for a MPP JVM+Android project generates a report only for classes and tests of the JVM target, but not for Android build variants
Solution
remove the default reports concept
clearly describe in the documentation the concept of the report variant
add report tasks (total reports) that will generate a reports for all classes of the build with the same names as the default reports now have (e.g. koverXmlReport, koverHtmlReport)
Total reports
Total report - this is a report on all classes and test tasks that are in a specific Gradle project.
Total reports does not have its own report variant, in fact it is a combined report on all the report variants available in the project.
Total coverage reports are always existed and can be called in any type of project, even if none of the Kotlin plugins are used. This is convenient when there are no sources in the root project, but the options from kover(project(":foo")) are taken dependencies and generated a merged report for all subprojects.
config example
koverReport {
total {
filters {}
xml {}
html {}
binary {}
log {}
verify {}
}
}
The text was updated successfully, but these errors were encountered:
- blocks kover and koverReports are merged
- added possibility of lazy configuration of Kover extensions
- removed the concept of default reports
- added the ability to create custom report variants
- Created interfaces for Kover tasks
Resolves#461Resolves#410Resolves#462Resolves#463Resolves#338
Motivation
At the moment, the concept of default reports is not obvious to the user
The word default/defaults is too ambiguous
Code like
the newbie user can be read as “default filters for all reports”.
Without reading the documentation, it is not clear what exactly the defaults block is used for.
Default reports solve too many things
Default reports both generate reports only for classes from JVM targets, and also used in Android projects to get a report on few or all of the build variants - by using mergeWith(“variantName”).
default reports behave differently for different project types
Calling the
koverHtmlReport
task for a JVM project leads to the generation of a report on all classes from the project.Calling the
koverHtmlReport
task for a Android project leads will not generate anything until the user explicitly writeskoverReport { defaults { mergeWith("release") } }
.Calling the
koverHtmlReport
task for a MPP JVM+Android project generates a report only for classes and tests of the JVM target, but not for Android build variantsSolution
koverXmlReport
,koverHtmlReport
)Total reports
Total report - this is a report on all classes and test tasks that are in a specific Gradle project.
Total reports does not have its own report variant, in fact it is a combined report on all the report variants available in the project.
Total coverage reports are always existed and can be called in any type of project, even if none of the Kotlin plugins are used. This is convenient when there are no sources in the root project, but the options from
kover(project(":foo"))
are taken dependencies and generated a merged report for all subprojects.config example
The text was updated successfully, but these errors were encountered: