We'll wait for the testing proposal integration since it will change how this all works.

Well maybe it wouldn't be too hard to do it currently? /cc @ddunbar

If there is a real solution coming soon, I wouldn't worry about spending effort trying to implement a temporary stand-in.

Yeah, I agree we should focus on getting the real testing solution in place, and then tackle this there.

Just my two cents: the parallelization of tests should be left to the test runner. A proposal should be made on swift-corelibs-xctest that allows the user to specify the number of concurrent runners when invoking XCTMain(). Supporting test parallelization in the package manager would cause some serious integration issues with Apple XCTest down the line, should we ever choose to do so--that framework is coupled to serial execution of tests.

Last I checked, the testing proposal was headed in a direction where test execution itself was left to testing frameworks like swift-corelibs-xctest, so I'm sure we can support parallelization in swift-corelibs-xctest after that proposal is merged.

@modocache I agree. So the XCTest runner certainly can have parallelism.

I'm assuming there's a way to hook into the pretty graphic that runs as part of the swift build-script --test option?

By pretty graphic, I assume you mean the progress bar? I like it a lot, too! I'm not sure how easy it would be to reuse it--last I checked the progress bar animation was part of @ddunbar's lit test runner. We'd have to port that Python code over to something the SwiftPM or XCTest could use in Swift.

Yeah, the progress bar comes from lit. It is pretty straightforward and could be ported easily (minus the usual pain of bridging to nasty C APIs).

I am of two minds on the parallelization of tests:

• On the one hand, I generally agree with Brian, it is a responsibility that should be left to the test framework.

• On the other, lit has proven incredibly useful at adapting existing test suites and running them in parallel (I even have an implementation that works with XCTest, using one process per test). I have used lit to execute, in parallel, tests written using: Python unittest, Google test, XCTest, and DejaGNU.

In addition, there are a couple of arguments for why an ideal system would integrate the parallelization of tests:

• Managing parallel execution of the build + test process is something the build system is designed for.

• Any system capable of doing particularly fancy things with tests (e.g., automatically running in the background, or only running the ones whose inputs have changed) likely already has the information necessary to run them in parallel.

• The actual implementation of parallelization is often not particularly interesting, having a single implementation instead of needing each testing framework to provide one reduces overall effort.

Given those, I am tempted to argue that defining the testing framework in such a way that swiftpm may run the tests in parallel would be useful, but allow options such that if the testing framework would rather manage it it can.

Having mulled on this I think we should leave it up to the XCTest team to add parallelization support, however we can still do it for SwiftPM by special casing our test product output, though this will need to wait on our Package.swift proposal.

In the mean time we can speed up our tests a good deal, I just opened a ticket about this. SR-804

Looks like @aciidb0mb3r has a PR open for this now: #583

This looks like an old bug that can be closed - the PR landed and you can invoke `swift test --parallel` to leverage it

Agreed... we don't currently run the tests in parallel in CI, but maybe we should?

I recently added a --test-parallel option to bootstrap script but forgot to ask if we should enable that for Swift CI!

I think we should, it speeds things up and will ensure we keep it working.

apple/swift#8153