Gradle7.4でテストレポートの統合へ

原文(投稿日：2022/03/14)へのリンク

Gradleはオープンソースのビルド自動化ツールのバージョン7.4をリリースした。これにより、開発者は集約されたテストとJacocoカバレッジのHTMLレポートを作成できる。バージョンカタログ機能を使うと、ビルドスクリプトで使う依存関係を一元的に宣言できる。共有ビルドサービスを使うと、複数のタスク間で状態またはリソースをキャッシュできる。

これらの最新機能を有効にするために、Gradle WrapperをGradle 7.4を使うように構成できる。

./gradlew wrapper --gradle-version=7.4

新しいtest-report-aggregationプラグインをJVM Test Suiteプラグインと共に使うと、Gradleプロジェクト全体でも複数のテストタスクのテスト結果を1つのHTMLレポートに結合できる。このプラグインによって、集約されたテストレポートが自動的に作成される。

plugins {
    id 'test-report-aggregation'
    …
}

dependencies {
    implementation project(':repositories')
    ...
}

application {
    mainClass = 'org.gradle.sample.Main'
}

tasks.named('check') {
    dependsOn tasks.named('testAggregateTestReport', TestReport) 
}

どのプロジェクトとテストスイートを使うかを設定することができる。./gradlew testAggregateTestReportを実行した後、HTMLレポートはapplication/build/reports/tests/unit-tests/aggregated-resultsフォルダーに配置される。

新しいjacoco-report-aggregationプラグインは、test-report-aggregationプラグインに相当するものである。それは、JaCoCoコードカバレッジレポートを、おそらく複数のプロジェクトから、JVM Test Suiteプラグインを使用したテストスイートに基づく1つのHTMLレポートに結合するためである。このプラグインによって、集約されたテストレポートも自動的に作成される。

plugins {
    id 'jacoco-report-aggregation'
    …
}

dependencies {
    implementation project(':repositories')
    ...
}

application {
    mainClass = 'org.gradle.sample.Main'
}

tasks.named('check') {
    dependsOn tasks.named('testCodeCoverageReport', JacocoReport) 
}

改めてではあるが、どのプロジェクトとテストスイートを使かを設定できる。./gradlew testCodeCoverageReportを実行した後、XMLおよびHTMLレポートはapplication/build/reports/jacoco/testCodeCoverageReportフォルダーに配置される。

バージョンカタログ機能が安定版となり、プロジェクト間で共有するための依存関係とそのバージョンの宣言が可能になった。バージョンカタログは、settings.gradleあるいはsettings.gradle.ktsファイルで定義される。

dependencyResolutionManagement {
    versionCatalogs {
        libs {
            library('micronaut-http', 'io.micronaut:micronaut-http-client:3.3.3')
        }
    }
}

複数のコンポーネントに対して特定のバージョンを宣言して再利用することができる。

dependencyResolutionManagement {
    versionCatalogs {
        libs {
            version('micronaut', '3.3.3'
            library('micronaut-http', 'io.micronaut', 
                'micronaut-http-client').versionRef('micronaut')
	        library('micronaut-runtime', 'io.micronaut',
                'micronaut-runtime').versionRef('micronaut')
        }
    }
}

バージョンカタログはbuild.gradleファイルで使用できる。ここで、libsはバージョンカタログであり、micronaut-httpとmicronaut-runtimeはカタログ内の依存関係の名称である。

dependencies {
    implementation libs.micronaut-http
    implementation libs.micronaut-runtime
}

いくつかの依存関係を1つのバンドルに結合できる。

dependencyResolutionManagement {
    versionCatalogs {
        libs {
            version('micronaut', '3.3.3'
            library('micronaut-http', 'io.micronaut', 
                'micronaut-http-client').versionRef('micronaut')
            library('micronaut-runtime', 'io.micronaut',
                'micronaut-runtime').versionRef('micronaut')
            bundle('micronaut', ['micronaut-http', 'micronaut-runtime'])
        }
    }
}

バンドルにより、build.gradleの構成をシンプルにできる。

dependencies {
    implementation libs.bundles.micronaut
}

または、カタログをTOMLファイルとして保存することもできる。デフォルトでは、libs.versions.tomlファイルはlibsカタログに読み込まれる。

[versions]
micronaut = "3.3.3"

[libraries]
micronaut-http = 
    { module = "io.micronaut:micronaut-http-client", version.ref = "micronaut" }
micronaut-runtime = 
    { module = "io.micronaut:micronaut-http-client", version.ref = "micronaut" }

[bundles]
micronaut = ["micronaut-http", "micronaut-runtime"]

[plugins]
…

ユーザーガイドでは、プラグインの構成や複数のカタログを使う可能性など、考えられるすべてのオプションについて詳しく説明している。

Oracle LabsのMicronautおよびGraalVMチームメンバーのCédric Champeau氏が、どのようにバージョンカタログ機能を使ってMicronautの依存関係を管理するかについて説明している。Micronautは、BOMの代替としてバージョンカタログをすでにリリースしている。Micronautバージョンカタログは、Gradle 7.4のMicronautプロジェクトで、MavenセントラルのBOMロケーションからインポートできる。

dependencyResolutionManagement {
    repositories {
        mavenCentral()
    }
    versionCatalogs {
        create("mn") {
            from("io.micronaut:micronaut-bom:${micronautVersion}")
        }
    }
}

mnとして参照される新しいバージョンのカタログは、build.gradleファイルで使用できる。Kotlin DSLはさらにコード補完を提供し、依存関係の表記はタイプセーフである。

ビルドサービスはもう1つの新しい安定版の機能で、それによってタスク間で状態またはリソースを共有できるようになる。ビルドサービスは、キャッシュやデータベースインスタンスなどの状態を保持するオブジェクトである。Gradleは、ビルドサービスを自動的に作成および削除する。ビルドサービスは、BuildServiceインターフェイスを実装し、オプションで1つ以上のカスタムパラメーターを定義することによって作成される。

public abstract class CacheBuildService implements BuildService<CacheBuildService.Params> {

    interface Params extends BuildServiceParameters {
        Property<Integer> getCustomParameter();
    }

    private final Map<String, Integer> cachingMap = new HashMap();;

    public CacheBuildService() {
        int customerParameter = getParameters().getCustomParameter().get();
        cachingMap.put("James", customerParameter)

        System.out.println(String.format("BuildService: Cache contains value %s", 
            cachingMap.get("James")));
    }

    public Map<String, Integer> getCachingMap() {
        return cachingMap;
    }
}

次に、以前に構築されたCacheBuildServiceを使うタスクが作成される。

public abstract class CacheTask extends DefaultTask {
    @Internal
    abstract Property<CacheBuildService> getCache();

    @TaskAction
    public void useCache() {
        CacheBuildService cache = getCache().get();
        Map<String, Integer> cachingMap = cache.getCachingMap();
        System.out.println(String.format("Task: Cache contains value %s", 
            cachingMap.get("James")));
    }
}

最後のステップでは、プラグインを定義し、オプションのカスタムパラメーターを指定して、タスクをCacheBuildServiceProviderに接続する。

public class CachePlugin implements Plugin<Project> {
    public void apply(Project project) {
        Provider<CacheBuildService> cacheBuildServiceProvider = 
                project.getGradle().getSharedServices()
                .registerIfAbsent("cache", CacheBuildService.class, spec -> {
            spec.getParameters().getCustomParameter().set(42);
    });

    project.getTasks().register("cache-example", CacheTask.class, task -> {
        task.getCache().set(cacheBuildServiceProvider);
        task.usesService(cacheBuildServiceProvider);
    });
  }
}

./gradlew clean -q cache-exampleでプラグインを実行すると、次のように表示される。

BuildService: Cache contains value 42
Task: Cache contains value 42

使いやすさについていくつか改善された。IntelliJ IDEAプラグインは、JVM Test Suiteプラグインによって使用されるすべてのソースディレクトリをテストソースディレクトリとして自動的にマークするようになった。Gradleの依存関係の検証では、プラグインのチェックサムとプロジェクトの依存関係が検証される。依存関係検証ファイルの生成はより安定しており、ビルド構成と検証ファイルが変更されない場合には同じ結果となる。

Javaツールチェーンを使うと、JvmVendorSpecクラスを介して目的のJavaバージョンを構成できる。AdoptOpenJDKのEclipse Adoptiumへの移行と、IBM Semeru Runtimesの導入により、新しいフィールドのADOPTIUMとIBM_SEMERUがベンダーとして追加された。ADOPTOPENJDKフィールドを使うと、非推奨の警告を表示できる。

構成キャッシュが改善され、現在は非推奨のProvider.forUseAtConfigurationTime() APIを使う代わりに、環境変数、システムプロパティ、Gradleプロパティを自動的に検出するようになった。

Kotlin DSLによって、リポジトリブロックにカスタム拡張用のタイプセーフなモデルアクセサーを作成できるようになった。これにより、たとえばwithGroovyBuilderを削除することで、より簡潔な構成を作成できる。

repositories {
    withGroovyBuilder { // This line is now optional
        "ruby" {
            "gems"()
        }
    }
}

バージョン7.4でのすべての変更に関する詳細は、リリースノートに記載されている。