Fails when using Xcode parallelized test plan

[RobinDaugherty]

When Xcode has parallelized testing enabled, it creates a series of "Clone" devices in which to run the tests.

MusselServer does well with multiple Simulator devices, but unfortunately in this case, the devices are not in the default device "set", so the server currently receives an error from simctl indicating that the device UDID is invalid.

I was able to verify that injecting --set testing into the command line used by MusselServer fixes the issue for parallel test runs.

Possible Solutions

1. The test process determines that it's running in a parallelized mode and includes the device set in the HTTP payload it sends.

There doesn't seem to be anything built in to Xcode to indicate that the test is running with parallelization. But it's possible for the Test Plan that has it enabled to also supply an environment variable or other startup options, and the UI Test process can use these to determine how to communicate with MusselServer.

2. MusselServer is given a command-line option indicating which device set to interact with, then all commands issued by the process include that option.

Since MusselServer is designed to run once, and listens on a single port, this seems like a bad idea—some Mussel clients might be running outside the parallelized environment, but they would have no way to differentiate, nor can another MusselServer instance be started.

That could be worked around by using a different port for the "testing set" MusselServer process.

But this is also investing in the assumption that there are only ever 2 device sets: default (unnamed) and "testing". This is probably not a correct assumption, as I can see some workflows that would take advantage of device sets for other reasons.