kotlinx-kover icon indicating copy to clipboard operation
kotlinx-kover copied to clipboard

Move the current functionality of Kover Gradle Plugin to Kotlin Gradle Plugin

Open shanshin opened this issue 10 months ago • 0 comments

From now on, we will begin integrating the Kotlin Coverage into the Kotlin Gradle Plugin.

This is a task to implement the ideas mentioned in #608. Motivation remains, but the implementation steps have been slightly modified.

Motivation

Disadvantages of the current approach:

  • the complexity of the concepts used in Kover Gradle Plugin: it introduces its own concepts of artifacts, coverage measurement options, report variants, its own rules for combining variants, its own rules for merging reports. All these concepts do not fit well with Kotlin, and its look like an artificial pile-up
  • after creating a minimal Kotlin application, it is not obvious that you need to use a third-party utility to measure coverage
  • some Kover plugin settings duplicate existing settings, for example, the need to add an kover dependency when a implementation dependency has already been declared - this complicates the configuration for builds with a large number of subprojects
  • unobvious to configure Kover as a separate Gradle plugin that is not related to Kotlin in any way
  • difficulty of supporting two Gradle plugins in the IDE - it is easier to support one Kotlin Gradle Plugin than two plugins with different versions
  • the current plugin DSL is specific to Java or JaCoCo in many respects
  • complicated integration with the Kotlin compiler
  • different lifecycle of Kover Gradle Plugin and Kotlin Gradle Plugin potentially complicates delivering support for new compiler features

Continued development of the current separate Kover Gradle Plugin

There will be no new features, changes, or improvements to Gradle DSL.

The only feature that will be added to Kover Gradle Plugin is the integration with Android Gradle Plugin.

Incompatibility bugs with future versions of Gradle will also be fixed until Coverage in Kotlin Gradle Plugin becomes stable.

Migration steps

Phase 1

  • develop a basic architecture for evaluation coverage in Kotlin
  • fix QoL bugs:
    • #615
    • #693
    • #712
    • #714

Phase 2

  • make JaCoCo the default agent (#720)
  • integrate with Android Gradle Plugin (#96)
  • develop a detailed Kotlin Coverage design based on the Kover experience and open issues (listed below)
  • make a decision about the move of Kover history to Kotlin repository
  • make a decision about the merging reports (Kotlin Settings Plugin, separate Coverage Settings Plugin, other)

Phase 3

  • implement prototype of Kotlin Coverage in Kotlin Gradle Plugin for JVM and Android platforms

Phase 4

  • collect feedback
  • stabilize prototype functional and Gradle DSL
  • add Kotlin Coverage to Kotlin Maven Plugin

Phase 5

  • release stable Kotlin Coverage as part of Kotlin Gradle Plugin and Kotlin Maven Plugin (for JVM and Android)
  • end support for the separate Kover Gradle Plugin
  • decide on the implementation of the compiler plug-in to support other platforms (#293)
  • these steps are not final and may be changed during the design of the Kotlin Coverage architecture, as well as for technical reasons.

Open issues analysis

The bugs and suggestions listed below should be taken into account in Kotlin Coverage for Kotlin Gradle Plugin (or Maven)

Kotlin-specific Coverage Report

It is necessary to develop a report that will allow exporting information about code coverage. This report should contain complete information that will be sufficient to transfer to external utilities, merge with each other, and convert to other universal formats.

  • #279
  • #494
  • #498

Reports filtering

  • #332
  • #676
  • #690

Kotlin Coverage HTML Report

  • #272
  • #443
  • #474
  • #553

External report formats

  • #67
  • #242

Integration with external tools

Integration with external tools will be performed after initial stabilization of DSL for Kotlin Coverge in KGP

  • #16
  • #260
  • #268

IDE

  • #267

Instrumentation

  • #418

Gradle

  • #605
  • #453
  • #476
  • #487
  • #533
  • #695

Functional tests

Functional tests should be easy to read, and error messages should help you understand the root cause of the error. Different versions of Gradle should be checked, as well as possibly different versions of Android.

  • #481

Compiler plugin

  • #250
  • #293

shanshin avatar Jan 03 '25 15:01 shanshin