Description
Motivation
Some tests require provisioning of resources that cannot be used concurrently. Knowing the amount of parallelism in the test suite (i.e. the number of worked threads), would allow for provisioning the correct number of resources.
For a concrete example, when testing a web application against a real (not mocked) database, I need to provision a database with the necessary schema. To be able to test transactionality essentially requires providing each thread with its own database. I do this (inspired by Django's test framework), by provisioning test database 0 through N-1 for N worker threads.
I have experimentally verified N at 8 or 9 (unclear, I use 9 just in case) on my MacBook Air, but I'm unclear if this is the hard-coded default or based on N+1 CPU cores for example, common for worker thread provisioning. I have worked around this by providing a TEST_DATABASE_COUNT=9 environment variable, this is however less than ideal because a) if swift test was passed a different --num-workers, the environment variable would need updating separately, and b) when running a single test, a single suite, or some other subset via Xcode, the full count is still used, and (in my case) 9 test databases provisioned, even though only 1 may have been necessary.
Proposed solution
import Testing
Testing.testingNumWorkers // == Int(9)
Alternatives considered
Alternative names, swiftTestingParallelism, numWorkers, testWorkers, workerCount, etc. I have no particular preference and defer to the Swift Testing team.
This could also be exposed via a function, or it could be exposed as struct/class that needs to be instantiated to retrieve the config. It could be provided through some callback to a suite/test, although as I'd like to use it in a trait this would be an awkward API to use. It could also be provided to traits via a callback, this would be fine for my purposes but I don't see much precedent for it.
All of the above feel like implementation details that I don't have much preference between, and without knowing the internals of Swift Testing, don't know what would be easy or hard.
As for radically different approaches, --num-workers could be overridden by an environment variable, thus moving the source of truth towards what I'm currently using as a workaround. This would solve the source of truth part of the problem, and if Xcode used the environment variable rather than the argument, it may also solve the optimisation case, however I'd assume Xcode wouldn't do this as I expect that It's A Bit More Complicated Than That for its integration.
Additional information
No response