This message was deleted.

It can but IIRC you won't have type-safe accessors, sor

"integrationTestImplementation"(libs.kluent)

. I, for one, prefer moving my

testImplementation

to the

test

suite; YMMV.

To get type-safe accessors automatically I think you would need to move the definition of the test suite into a plugin that you then apply using the

plugins { ... }

block. I think then you should get the accessors, but personally, I'm totally with @Thomas Broyer

Can you elaborate on this ? How exactly

testImplementation

cna be moved to test suite?

You already have

val test by getting...

. Add to the closure a

dependencies

block like for the integ tests

It does, you can give that method a version and that version can come from a version catalog.

• It takes a

String

or

Provider<String>

so you can't just pass

libs.versions.junitJupiter

, and this prevents using rich versions • It means you configure not dependencies but just a version, making the versions catalog heterogeneous • This also prevents using forks with different GAV I think what I dislike the most actually is that

useJUnitJupiter()

is the default for all new test suite besides `test`; I thought we all agreed that adding implicit dependencies was a smell? And if I have to explicitly call

useJUnitJupiter()

or whatever for the

test

suite, why is it different for other suites? (I know

test

is for backwards compatibility; I'm questioning why it was done differently for non-default suites)

It takes a

String

or

Provider<String>

so you can't just pass

libs.versions.junitJupiter

,

... why not?

libs.versions.junitJupiter

is a

Provider<String>

.

and this prevents using rich versions

Well, partly.

libs.versions....

supports rich versions to a certain degree. But indeed not fully, yeah. If you need the full rich version support, you can still declare the dependency manually.

It means you configure not dependencies but just a version, making the versions catalog heterogeneous

I don't agree. The version catalog even has in the name that it declares versions. Indeed it is meant to declare versions, library coordinates, plugins, and bundles. And using either of them is fine. You (well I) for example also declare the Java version to use or the JaCoCo version to use which I then use for the JVM Toolchain configuration or the JaCoCo

toolVersion

property.

This also prevents using forks with different GAV

Well, not prevents, you can still add the fork as dependency and then use capability conflict resolution to select the fork. Yes, this is not too convenient, but for the benefit of more convenience in the 90 % case where the standard coordinates are used, while still providing the flexibility to use what you want.

I think what I dislike the most actually is that

useJUnitJupiter()

is the default for all new test suite besides `test`;

Why? While I prefer Spock for basically everything as it makes testing fun again, Jupiter is probably the most widespread one currently and thus a good choice for a conventional default. Remember, Gradle is about convention over configuration while providing the flexibility to configure whatever you like. Jupiter is just the convention and you can anytime select a different one via configuration by using a

use...

method.

I thought we all agreed that adding implicit dependencies was a smell?

I don't think we agreed on that anywhere or even discussed it anywhere. Implicit dependencies that are not opitional, I would probably agree. But default dependencies as convention that you can override are imho perfectly fine and used in several places, like the JaCoCo dependency, the Checkstyle dependency, the PMD dependency, .....

And if I have to explicitly call

useJUnitJupiter()

or whatever for the

test

suite, why is it different for other suites? (I know

test

is for backwards compatibility; I'm questioning why it was done differently for non-default suites)

Probably because JUnit 4 is old and stinky, and using it as convention for the new stuff just because the one

test

one needs to stick with it for backwards compatibility would be more consistent, but highly questionable.

... why not?

libs.versions.junitJupiter

is a

Provider<String>

.

Ah yes, was used to using the non-type-safe API where

findVersion

returns an

Optional<VersionConstraint>

. Everything else (declaring dependencies in addition to that, adding capability conflict or whatever) is just a workaround that wouldn't be needed if Gradle didn't insist in adding dependencies itself without the user asking for it and without any way to opt out. YMMV

I totally agree that a

useNone()

and especially a

useJUnitPlatform()

are missing.