This message was deleted.

I tried running

./gradlew.bat --stop

in-between the tests, however, it stops all the daemons, not just idle ones, so the build terminates

Adding

--no-daemon

to runner args along with tasks doesn't help?

--no-daemon

is explicitly unsupported in

GradleRunner

, and it just throws an error

I suppose you're testing for a list of Gradle versions? (or otherwise use some arguments that prevent reusing the same daemon) Maybe you could test one at once, with several runs of Gradle so you could

--stop

in between tests (I personally use a job matrix so those tests can run in parallel)

I’m using parameterized test over gradle verisons

maybe a stupid idea, but have you tried executing

System.exit(0)

in the context of a build under test?

The TestKit uses dedicated daemon processes that are automatically shut down after test execution.

— https://docs.gradle.org/current/userguide/test_kit.html#sec:controlling_the_build_environment

I stopped using TestKit and instead use Java

ProcessBuilder

to start an actual Gradle build. There simply are too many things that do not work properly in TestKit and one ends up doing more debugging of it, instead of testing. I recommend to do the same here, as it is going to unlock what you need.

You could call in

tearDown()

-

ConnectorServices.reset()

. But this will stop all currently running Gradle daemons, so may not work for you if you are running tests in parallel

I am puzzled a this point. It looks like the machine had enough RAM (~2G of 7G was reported as “free” just before the failure) I was able to customize testkit-based daemons via

((DefaultGradleRunner) runner).withJvmArguments("-Xmx1024m")

, however it did not help either. So I just stopped, and I excluded “windows + java8” from CI matrix. @Fleshgrinder, do you think you could suggest pointers to “no-testkit” style of writing tests? I can imagine several ways, however, I don’t want to reinvent the wheel :)

I do have plans on releasing a library, currently I'm only using it in closed source projects. Let me dump what I have into a public repository so that you can copy it until I find the time to package it up. (Gimme a few minutes for that.) For me the problem started while testing custom Gradle distributions that are auto-configuring repositories. This fails miserably with the

GradleRunner

because repositories cannot be changed at all with it. Another huge issue is that Gradle keeps locking things all over and relies on the advisory locking of POSIX systems, which obviously fails miserably too on systems with mandatory locking (e.g. Windows). The testing kit that is based on Java's

ProcessBuilder

solves all issues. Builds work exactly as you think they work. Concurrent/parallel execution is no problem at all, since each build is hermetic. The Gradle process either finishes successfully, fails, or gets killed by a timeout. Piping input is no problem, so, testing of interactive things is no problem either. The only downside (if it can be considered one) is that you cannot access the outcome of individual tasks. This would require some output parser, which is doable, but probably going to be fragile over time. I use https://strikt.io/ which has many great assertions for working with text. I either check the output with

contains

and

matches

or massage the output so that the build only prints what I actually need, then I can use

isEqualTo

. Attached is an example test for a closed source custom Gradle distribution (there's nothing special in this, so posting it won't disclose anything interesting other than the company). Note that I'm running all tests in parallel on my AMD Ryzen 9 3900X (24 tests at the same time) on Windows (mandatory locking) without any hick-up.