This could be used to configure a different port number to to use in the tests for a http server started in the tests.
I can imagine that it could be useful to configure things per test JVM. In this particular case though, wouldn’t it be better to let the code that starts the server control which port is used?
In the particular case that sparked this that’s not possible because there are two parties that need to know about it.
But yes it would be preferable for the tests to find a port if possible.
Isn’t it necessary to communicate the port to the client anyway, be it via system property, static state, or some other means, even if set from Gradle?
Yes, but I’m not sure what you are getting at.
I don’t understand why it’s any easier to set the ports from the build script (given you need more than one port and hence can’t hardcode a port in the test clients) than from the test code that manages server startup/shutdown. And setting it from the test code solves the problem of needing different ports for different test JVMs.
By setting them in the buildscript they would be reserved. In this situation the test code launches a separate process that binds to the port so has to tell it what port to use.
No matter how and where the port is ‘reserved’, the test code needs to look it up anyway. So what’s the difference between reserving ports in the build script vs. reserving them in some test fixture code?