Am I correct that the `org.jetbrains.kotlin.multip...

# gradle

[mbonnin]

Am I correct that the org.jetbrains.kotlin.multiplatform plugin doesn't support the "test-report-aggregation" plugin ? If I try to aggregate KMP tests, they're no taken into account in the aggregate report.

[mbonnin]

test project: https://github.com/martinbonnin/test-kmp-test-aggregation

[Adam S]

I suspect it won't work by default. The Kotlin Multiplatform plugin tries to make it look like the java Gradle plugin is applied, but I guess it won't apply the required JVM Test Suite Plugin

But you might be able to specify the reports manually?
https://docs.gradle.org/current/userguide/test_report_aggregation_plugin.html#manual_report_creation

[Javier]

I have certain feeling when I see
• java-test-fixtures
• jvm-test-suites
And more I don't remember.

I think Gradle should focus on do abstract plugins, and provided first party support for Java if they want, but allowing third party plugins to provide support to not only kmp targets, even other languages that want to use Gradle as build tool.

[mbonnin]

Specifying the reports manually gives

:kmp-lib:testAggregateTestReport NO-SOURCE

[mbonnin]

Well, testAggregateTestReport should be in the root project 🤔

[mbonnin]

I'll hack my way into making something manually using the Junit XMLs

[mbonnin]

Question is whether this is something we want in the KMP plugin or not? If it's Java specific then it doesn't belong to KMP but if it's test-report specific then it'd be nice to have

[Adam S]

https://github.com/Kotlin/kotlinx-kover/ should work for KMP, and it has aggregation. I suspect that would be the alternative, rather than trying to integrate test-report-aggregation. Maybe Kover should be updated to be compatible with test-report-aggregation?

[mbonnin]

My (currentI) end goal is just to count the number of test so pulling kover just for that sounds like a huge hammer. But yea, I have no answer to the question whether the Kotlin ecosystem should support test-report-aggregation

[Adam S]

that sounds like one of those tasks that sounds very simple, but will actually be very complicated :)

[Vampire]

The JVM Test suites plugin registers an outgoing variant for each test suite with according attributes.
This variant is then collected by the test report aggregation plugin.
So to flange support on, you might be able to just create the according outgoing variants in the producers.

[Vampire]

https://github.com/gradle/gradle/blob/master/subprojects/plugins/src/main/java/org/gradle/api/plugins/JvmTestSuitePlugin.java#L127-L145

[mbonnin]

This was a good suggestion albeit looks like there's already an outgoing variant (with an empty non-existing dir as artifact 🤔 )

--------------------------------------------------
Variant testResultsElementsForTest (i)
--------------------------------------------------
Directory containing binary results of running tests for the test Test Suite's test target.

Capabilities
    - com.apollographql.apollo3:apollo-ast:4.0.0-alpha.4-SNAPSHOT (default capability)
Attributes
    - org.gradle.category              = verification
    - org.gradle.testsuite.name        = test
    - org.gradle.testsuite.target.name = test
    - org.gradle.testsuite.type        = unit-test
    - org.gradle.verificationtype      = test-results
Artifacts
    - build/test-results/test/binary (artifactType = directory)

I'll keep digging and update this thread if I find a solution I'm not too ashamed of 🙂

[Vampire]

Probably the test suite plugin is already applied. Maybe you just need to add the right artifact

[mbonnin]

Ah! found the culprit, I apply antlr , which applies java which applies jvm-test-suite

[mbonnin]

This is what I ended up with if anyone's curious. I gave up on test-report-aggregation for multiple reasons used TestResultSerializer directly instead