Add configuration hook for specifying different system properties for each concurrent test runner

(Luke Daley) #1

This could be used to configure a different port number to to use in the tests for a http server started in the tests.

(Peter Niederwieser) #2

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?

(Luke Daley) #3

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.

(Peter Niederwieser) #4

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?

(Luke Daley) #5

Yes, but I’m not sure what you are getting at.

(Peter Niederwieser) #6

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.

(Luke Daley) #7

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.

(Peter Niederwieser) #8

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?