kotlinx-kover

repository·main·Indexed 23 days ago

https://github.com/kotlin/kotlinx-kover

A suite of tools for collecting and reporting test coverage for Kotlin code targeting JVM and Android platforms. It includes a Gradle plugin, a Maven plugin, and a standalone Command Line Interface (CLI) for offline instrumentation, merging binary reports, and generating HTML and XML coverage reports.

Tokens
21.1K
Snippets
60
Records
99
Agent score
81%

What's inside kotlinx-kover

  1. Overview of Kover Toolset components

    main

    Kover provides several solutions for collecting test coverage of Kotlin code compiled for JVM and Android platforms:

    • Kover Gradle Plugin: For Gradle-based builds (JVM and Android).
    • Kover Maven Plugin: For Maven-based builds.
    • Kover CLI: A standalone JVM application for offline instrumentation and human-readable report generation (Requires JVM 1.8+).
    • Kover offline instrumentation: Modifies class-files stored on disk to measure coverage.
    • Kover JVM agent: A JAR file that modifies bytecode of classes as they are loaded into the JVM (Requires JVM 1.7+).
    • Kover features artifact: A JVM dependency for programmatic instrumentation of class-files on disk (Requires JVM 1.8+ and Kotlin 1.8.0+).
  2. Overview of Kover Gradle Plugin

    main

    Kover is a Gradle plugin designed to measure code coverage for tests running on the JVM and generate coverage reports. It supports both Kotlin JVM and Kotlin Multiplatform projects, including Android projects with build variants.

    Key features include:

    • Coverage Collection: Measures coverage through JVM tests (note: JS and native targets are currently unsupported).
    • Report Generation: Produces HTML and XML reports.
    • Verification: Allows setting verification rules with bounds to enforce coverage thresholds.
    • Automatic Task Management: Automatically creates report tasks and manages dependencies between them.
    • Smart Detection: Automatically detects project source code, compilation tasks, test tasks, and Android build variants to configure Kover tasks.
    • Language Support: Supports mixed Kotlin and Java sources.
    • JaCoCo Integration: Can use the JaCoCo library as an alternative for measuring coverage and generating reports.
  3. Use the Kover Command Line Interface (CLI)

    main

    The Kover CLI is provided as a single JAR artifact that allows you to access Kover Toolset functionality directly through command-line calls. This is useful for environments where the Gradle plugin is not available or for integrating Kover into non-Gradle-based workflows.

    For detailed command usage, flags, and configuration, refer to the full CLI documentation.

  4. What is offline instrumentation and when to use it

    main
    Offline instrumentation is a method of collecting code coverage by transforming the bytecode in compiled class files on the file system. Unlike Java agents, which instrument code at runtime, offline instrumentation modifies the class files themselves. This approach is suitable for runtime environments that do not support Java agents.
  5. Create and use Custom Report Variants

    main

    Starting with 0.8.0, the concept of 'default reports' has been replaced by Total reports and Custom reports.

    To combine multiple targets (e.g., a JVM target and an Android 'release' variant) into a single report, you must create a custom variant. A variant is a collection of project classes, test tasks, and exclusion rules.

    Steps to create a custom variant:

    1. Define the variant in kover.currentProject.createVariant("name").
    2. Use add("variantName") to include existing targets (like jvm or Android build variants).
    3. Configure report settings for that variant in kover.reports.variant("name").

    Task Naming Convention: Kover automatically generates tasks for your custom variant using the pattern: kover<Type>Report<VariantName>. For a variant named custom, tasks include koverHtmlReportCustom, koverXmlReportCustom, etc.

    kover {
        currentProject {
            createVariant("custom") {
                add("jvm")
                add("release")
            }
        }
    
        reports {
            variant("custom") {
                filters {
                    // filters only for custom variant
                }
            }
        }
    }
  6. Configure coverage verification rules

    main

    Verification allows you to set boundaries for coverage values. Kover divides code into units (lines, instructions, or branches) and groups them (by application, class, or package) to calculate a coverage value.

    Coverage Metrics

    • CoverageUnit: LINE (default), INSTRUCTION, or BRANCH.
    • AggregationType: COVERED_COUNT, MISSED_COUNT, COVERED_PERCENTAGE (default), or MISSED_PERCENTAGE.
    • GroupingEntityType: APPLICATION (default), CLASS, or PACKAGE.

    Setting Rules

    You can specify rules for all variants, the total variant, or a specific named variant.

    kover {
        reports {
            verify {
                rule {
                    minBound(50)
                }
            }
        }
    }
  7. Understand Kover functional test types

    main

    Kover functional tests run Gradle in a separate system process and verify the results. There are five distinct test types available for different testing scenarios:

    1. examples: Tests run against ready-made projects located in the examples subdirectory. These projects must use the latest release version of the plugin (defined by the releaseVersion property).
    2. templates: Tests targeting specific rare cases using projects located in the templates directory. You can execute any Gradle command for these projects.
    3. single generated test: Tests that launch a project without pre-existing source code. The project is built dynamically using a BuildConfigurator within the test code, allowing for versatile configurations of script languages, Kotlin plugins, or coverage tools.
    4. sliced generated test: Similar to single generated tests, but executed multiple times across different combinations of script language, Kotlin Plugin type, and Coverage Tool (collectively referred to as a "slice").
    5. simple test: Tests that do not perform any actions with Gradle; all logic must be implemented manually within the test code using available functions.
  8. Filter classes in Kover reports

    main

    Filtering allows you to include or exclude specific classes from reports and verification.

    Filter Types

    • classes: Filter by fully-qualified class name (supports wildcards * and ?).
    • annotatedBy: Filter by annotations (requires BINARY or RUNTIME retention).
    • inheritedFrom: Filter by class/interface inheritance.

    Priority and Levels

    Filters can be defined at different levels:

    1. Common level: Applies to all variants in the project.
    2. Variant level: Applies to a specific report variant (e.g., total or release).

    Important Rules:

    • If both includes and excludes are specified, excludes have priority.
    • A higher-priority filter (variant level) completely replaces the rules from the level below (common level).
    • To disable all filtering, use an empty filter block: filters { }.

    Note: Additional filters like annotatedBy do not work when using the JaCoCo coverage library.

    kover {
        reports {
            // Common filters for all variants
            filters {
                excludes {
                    classes("com.example.Class1", "com.example.Class2")
                }
                includes {
                    classes("com.example.Class1", "com.example.Class3")
                }
            }
    
            // Overriding filters for a specific variant
            variant("release") {
                filters {
                    excludes {
                        classes("com.example.OtherClass")
                    }
                }
            }
        }
    }
  9. Understand Kover HTML report colors

    main

    The Kover HTML report provides visual feedback on code coverage using the following color coding:

    • Green: Line has been executed at least once (covered).
    • Red: Line has never been executed (missed).
    • Yellow: Line contains branching, but at least one branch was not executed (partially covered).
    • No color: Code that was excluded from the report using filters.

    Note: HTML reports show coverage by lines; they do not provide detailed coverage for individual expressions or specific branches within a single line.

  10. Generate aggregated reports for multi-module projects

    main

    In multi-module projects where source classes and tests are distributed across different modules, you can generate a single combined report by enabling aggregation.

    To do this, add <aggregate>true</aggregate> to the Kover Plugin <configuration> block.

    How aggregation works:

    • Classes: The report collects classes from all modules specified in the <dependencies> block, excluding those with test scope.
    • Tests: Coverage is collected from tests located in modules specified in the <dependencies> block, including those with test scope.
  11. What are Binary reports?

    main

    A Binary report is an intermediate, non-human-readable coverage report. It serves as the input for generating human-readable formats like XML or HTML using third-party tools.

    Binary reports are particularly useful when coverage measurement and report generation occur on different machines or in separate Gradle builds. They can be used as input for the Kover CLI or the Kover Features artifact.