This message was deleted.

testFixtures

is a source set, not a configuration. So you get the same configurations for it like for other source sets

testFixturesImplementation

,

testFixturesCompileOnly

,

testFixturesCompileClasspath

, .....

JVM test suites?

I'll give it a look tomorrow, I didn't know it existed and the existing code was doing things based on a tutorial from years and years and years ago. It sounds ideal though.

Mind sharing the documents you refer to?

mmm, the one you shared, ... sec I'll find the other 2

that's the one we were using

Yeah, that sample simply pre-dates JVM test suites. And actually, JVM test suites are still incubating. This might be a reason that the sample was not removed or updated. But it is probably at least worth to add a note to the sample header that hints at the new JVM test suites. I'd recommend you open a feature request or pull request for that. 🙂

I'm going to reflect that on you, feel free to do that. I knew it predated it, it's just confusing to see 3 variants (yes I know I can't find one of them)

is this complete?

Probably

is this really the simplest thing that can work

No

why doesn't the documentation start with that! 😕

I don't know

strange... I added that (well similar) and now that dependency analysis plugin is saying

> Task :persons-client:projectHealth
Unused dependencies which should be removed:
  intTestImplementation libs.junit.api
  testImplementation libs.junit.api
  testImplementation libs.junit.params

testing {
    suites {
        intTest(JvmTestSuite)
        e2eTest(JvmTestSuite)
    }
}

They were required before and

@Test

would still need that...

If you are switching to test suites, I would also move the dependencies into the test suites dsl, but up to you. junit api is unlikely to be needed it should already be there by definig the test suite to use jupiter which is the default for additional test suites. Or do you not use jupiter but junit 4? Then you need to do

useJUnit()

for those test suites.

If you are switching to test suites, I would also move the dependencies into the test suites dsl, but up to you.

why would that be better? also guessing it would simply confuse our devs

Well, for Kotlin DSL at least it is better as you don't need to use string-y declaration or getting the configuration by name. For Groovy DSL the difference is less. But I still prefer to have the test suite related setup together, configuring the test task, configuring the test dependencies, ...

I did not specify the platform further, it's applied to

test

through a plugin, does it need to be specified further?

Yes, as I said 🙂

although it looks like they aren't running, probably need to add the after, at least for the debatable integration test that runs today

The "after" - if you mean the "shouldRunAfter(test)" - just means that if you run integration tests and unit tests in the same Gradle run, unit tests should run first as they are usually faster.

well, I suppose I mean the check depends on

If you want

check

to depend on the additional test suites, you have to manually configure that, yes.

I find that order a little questionable, because, kind of meh? but can't gradle run them concurrently otherwise? don't know if it will

Not everyone wants to run potentially long-running integ tests or ui needing e2e tests or similar as part of

check

sure, I'm leaving the e2e's out

Without configuration cache, tasks within one project can never be run in parallel, except they are specifiically designed to run in parallel using the worker api

Gradle can run the test tasks in parallel only if you use configuration cache

which is disabled in the github ci action

cc is not disabled, its state is just not preserved

so how does it decide the order if you don't define it?

But you still get the benefit of all tasks running in parallel with cc enabled

my mistake 😕

if you don't define order between tasks with an explicit contraint or some dependency, there is no guaranteed order.

effectively not cached because... reasons that are not gradle's fault? although, does gradle have a way to say "don't cache this"?

It can be random which runs first depending on what other things already finished, or what you requested in which order from command line

I mean that you have to recreate it every time, because it's not stored in the cache that is kept between runs

You want to say "don't cache this" for something that is not cached? confused

I guess, I'm just miffed that github is calling the configuration cache a security vulnerability

Yes it does

testing {
    suites {
        intTest(JvmTestSuite) {
            targets {
                all {
                    testTask.configure {
                        shouldRunAfter(test)
                    }
                }
            }
        }
        e2eTest(JvmTestSuite)
    }
}

I think this replicates what we had, doesn't seem significantly shorter 😕

With CC enabled, also tasks can run in parallel which speeds things up

we don't need a new language dsl, we need a better api

like somehow it feels like I should be able to write

Well, yes and no, only in the current state. But in some future you will be able to have multiple test targets each with its own or maybe even multiple test tasks. The DSL is already prepared for that to not need to then again change it right away.

I mean... but there could still be the more complex api... that also exists

Well, if both APIs would be there, you would yet again have two ways to do the same thing and thus increased uncertainty what to use.

eh, I probably wouldn't care much if I had parallelism

just start all 3 at the same time!

Yeah, as I said, that you get when you use configuration cache and the tasks do not have an ordering constraint like

mustRunAfter

or

dependsOn

, even if configuration cache state is not preserved.

I'm quite certain that configuration cache isn't going to work right now