This message was deleted.
# community-support
s
This message was deleted.
v
If you do
useJUnitJupiter()
, you do not need to add Jupiter explicitly. And you do not need it for
functionalTest
. It does not "inherit" anything, it simply is the default of newly created test suites. For the
test
suite the default is just different for backwards compatibility.
thank you 1
a
Thanks! Is there a way to exclude transitive dependencies from a test suite dependencies block?
v
Like for the normal dependencies block?
👍 1
While in many situations excluding is not the semantically right thing to do actually, 🙂
Most often if you are tempted to exclude something, it is because of faulty declared transitive dependencies and it would be better to use a component metadata rule to fix that (https://docs.gradle.org/current/userguide/dependency_downgrade_and_exclude.html#sec:excluding-transitive-deps last paragraph)
a
Yes like the normal dependencies block
v
Even it was formulated as question, it was the answer ;-)
🙌 1
Like "do it like usual, or why does that not work for you?" 🙂
Sometimes it is hard to get the right intonation with written words 😄
a
Ya I do agree but in this case was to remove a transitive dependency which shouldn't be there 😛
v
you want to remove something that should be there? * confused *
a
sry typo
😂
v
Yes, that's what excludes do. But componente metadata rules can too, if it for example is about wrongly declared dependencies and not just "the dependency is correct, but I really don't want it." 😄
a
Ya but in that case we would just update it to another version
in this case we really don't want that transitive dependency as it shouldn't be there
Additionally, would like to ask if Gradle test suites is something that you currently use/used in the past and would recommend over manually setting the configurations/tasks
v
Yes and yes
thank you 1
a
how would one control transitive dependencies then?
v
When "then"? And which kind of control?
Upgrade, downgrade, fixing wrong metadata, adding feature variants, ....
a
I think im a little confused as I don't have the same configuration options as when using the default dependencies block like on top level build.gradle declaration
when using test suites dependency block
v
Why not? Which Gradle version? What do you miss?
Which DSL?
a
version 7.5.1 kotlin dsl
im doing the following:
Copy code
testing {
    suites {
        val test by getting(JvmTestSuite::class) {
            useJUnitJupiter()
            targets {
                all {
                    testTask.configure {
                        outputs.upToDateWhen { false }
                        reports.junitXml.outputLocation
                            .set(file("$buildDir/junit-reports"))
                        testLogging {
                            exceptionFormat = FULL
                            events = setOf(FAILED)
                            showStandardStreams = true
                        }
                    }
                }
            }
        }
        val otherTest by registering(JvmTestSuite::class) {
            useJUnitJupiter("5.10.1")
            dependencies {
                runtimeOnly("org.junit.vintage:junit-vintage-engine:5.10.1")
                ...
                implementation(Dependencies.ElasticsearchClient.dependency) {
                    exclude("commons-logging", "commons-logging") // does not work
                }
            }
        }
    }
}
in this case I know that the elasticsearch dependency is a module dependency then I could make something like
Copy code
(this as ModuleDependency).exclude("commons-logging", "commons-logging")
v
In one of the later 7.x versions, could be 7.6, the API was reworked to fix some shortcomings. Try to update to latest 7.x if you can, then check again
a
thanks! will check on that!
v
Yep, 7.6 it was
a
Ya it worked! thanks!
Hey, quick question - in case I need project dependencies in my test suite I've seen
implementation(project(path))
as the way to go but it is not working for me 😓
also
implementation(project())
does not work either from the docs https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html
v
Are you on 7.6+ now or still on 7.5. This also changed there iirc.
Just
implementation(project)
iirc
v
You are on 8.4. He is (or at least was 2 days ago) on 7.5, that's why I asked. And as I said, the syntax changed in 7.6. 😉
a
7.6.4
implementation(project)
gives me an error
v
There
implementation(project())
should work properly and does for me
a
ya it doesn't o.o
no project dependencies on my suite classpath
v
Of course not. That adds a dependency on your production code and as usual
implementation
dependencies do not leak into downstream compile classpaths.
a
ahh
makes sense
its the same as a library when using API
👍 1
i get it
thought it would do the same as test default suite
v
If you would really want to have the same dependencies you declare on the main sourceset for that test source set, make the test source set configurations extend the respective main source set configurations.
a
ya
v
Nah, the
java
plugin does exactly that. It makes
testImplementation
extend from
implementation
and
testRuntimeOnly
extend from
runtimeOnly
.
Typically additional test suites are more like functional tests or integration tests or system tests and most often these should not share the same dependencies.
a
ya exactly the thing is there are common dependencies xD
v
Yeah, well, either declare them on both, or make all dependencies inherited, or if you just want to share those common ones, create an additional custom configuration that is neither resolvable nor consumable and make
implementation
and
testImplementation
extend from this new configuration, then you share exactly those.
🙌 1
a
Yup will check on that! Thank you very much 😄
👌 1