I have a library with some extensions over jassert. The minimum version that I support is 3.0.0 and that's the dependency that my module exposes. But that version is old and it's most likely overwritten on the user side for a newer version. Based on this scenario I would like to run the unit tests that I have for my module against 3.0.0 and the newest version of jassert (the newest version will be updated by renovate bot). Same tests, the only change is the runtime dependency version. How can I do this in "the grade way"? Are the test suites a good fit for this scenario?

yes test suite are a good fit for this scenario. I would just recommend to double check that each suite gets the jassert vertsion you are expecting it to get.

Yep, something like

val otherVersionTestRuntimeOnly = configurations.dependencyScope("otherVersionTestRuntimeOnly")
val testRuntimeClasspath by configurations.existing
val otherVersionTestClasspath = configurations.resolvable("otherVersionTestClasspath") {
    extendsFrom(otherVersionTestRuntimeOnly.get())
    extendsFrom(testRuntimeClasspath.get())
    attributes {
        attribute(CATEGORY_ATTRIBUTE, objects.named(LIBRARY))
        attribute(USAGE_ATTRIBUTE, objects.named(JAVA_RUNTIME))
        attribute(LIBRARY_ELEMENTS_ATTRIBUTE, objects.named(JAR))
        attribute(BUNDLING_ATTRIBUTE, objects.named(EXTERNAL))
        attribute(TARGET_JVM_ENVIRONMENT_ATTRIBUTE, objects.named(STANDARD_JVM))
    }
}

dependencies {
    implementation("depen:dency:3.0.0")
    otherVersionTestRuntimeOnly("depen:dency:4.0.0")
}

testing {
    suites {
        named<JvmTestSuite>("test") {
            val testOtherVersion by targets.registering {
                testTask {
                    classpath = objects.fileCollection().from(
                        sources.output,
                        sourceSets.main.map { it.output },
                        otherVersionTestClasspath
                    )
                }
            }
        }
    }
}

Or something around the lines

I was thinking something like the example shown here: https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html#sharing_configuration_between_multiple_test_suites just instead of integration and functional test, use legacy and current test. and runtimeOnly instead of implementation.. make them use the same sourcecode, as shown here: https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html#configure_source_directories_of_a_test_suite not sure if there are noteworthy differences between registering 2 tasks for one testsuite or registering 2 testsuites using the same sources... @Vampire does my solution have an technically unecessary compilation?

Not fully sure what your setup would look like and do, but I guess it would compile the sources twice given the link you shared. You can for sure also configure it in a way that it does not compile the sources twice even with two different source sets. But I think the main problem in the docs there is, that they are written with the beginning state in mind that only one

target

with one

testTask

is supported per

testSuite

. There are still places that state that, but indeed it works to have multiple `target`s now and the upgrade guide even suggests to use it at one point. So if you want to run the same tests just with a different environment, I think multiple `target`s is the more idiomatic way. Also see: https://github.com/gradle/gradle/issues/35708