Without those options, import Testing and macros such as @Test were failing to compile.
Would I need to add similar options to test/lit.cfg for each supported platform?
The ST-0002 proposal suggests that I should be able to use either Runner or ABI.v0.entryPoint directly. However, neither of those SPI symbols were found:
warning: '@_spi' import of 'Testing' will not include any SPI symbols; 'Testing' was built from the public interface at /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks/Testing.framework/Modules/Testing.swiftmodule/arm64-apple-macos.swiftinterface
Instead, I had to use boilerplate code from the Building with CMake document. (This could be shared by other test suites as a protocol extension.)
Hey Ben—thanks for your interest in Swift Testing. I'm going to start by telling you flat-out "don't do this (yet)." Swift Testing is not designed to be used to test the Swift standard library or its related modules. We absolutely want to be able to do it, but we need to sit down with the core team and plan out how to make it happen. This way lies madness.
In particular, the prebuilt copy of Swift Testing in Xcode links to the prebuilt copy of the Swift standard library on the target Apple device, so you'll likely end up with two copies of the standard library loaded into the test process: the one on the device and the one you've built for testing. This is not a supported configuration.
Swift Testing is not part of the platform SDK and it is expected that you would need to provide additional paths to find its various components if you're not building a standard Xcode test target (or the Swift Package Manager equivalent.)
I would imagine so, yes. Whatever solution we ultimately provide for testing the Swift standard library would, I hope, abstract away this particular detail.
That's expected: those symbols are only visible if you build Swift Testing from source. Otherwise, you can get at the entry point function via its C synonym as you've discovered. But, as I said previously, you'll be running the prebuilt Swift Testing and linking to the prebuild Swift standard library, so… don't.
Very roughly speaking, and without having talked to the core team about it recently: I expect the way forward when we do add support for testing the Swift standard library will involve building Swift Testing from source alongside the Swift standard library so that everything links to the correct copies of everything else. We'll also need some sort of bespoke harness tool/process/binary/??? that invokes either Runner or the entry point function using arguments passed in from lit.
