swiftlang
Link to tool-specific documentation about adding test resource files
Description
As far as I can tell, the docs don't explain how one should add resources that might be needed for unit tests, like test data files.
Expected behavior
A section showing how where to add test resources
Actual behavior
No response
Steps to reproduce
No response
swift-testing version/commit hash
No response
Swift & OS version (output of swift --version && uname -a)
No response
The instructions for how to do this depend on which tool you are using to build and run your Swift Testing tests. For example, when using a package you might use SwiftPM's instructions for adding resources, while an Xcode project uses a different workflow and runtime API.
If you're using an Xcode project, I'd encourage filing a Feedback with Apple with any documentation enhancement requests. But if you're using SwiftPM, does that documentation I linked above provide sufficient guidance?
We could still link to those tool-specific resources from the swift-testing docs, though. We can use this to track that.
The instructions for how to do this depend on which tool you are using to build and run your Swift Testing tests.
Well, in this case, it's SPM, but I'm using Xcode to edit and run it. This issue was prompted by me reading somewhere that the PWD was set to the target root, and trying to build a path based on that. This is true when running tests from the command line (e.g.swift test), but not true when running tests from Xcode (it becomes /private/tmp). So I started researching how to properly add resources.
We could still link to those tool-specific resources from the swift-testing docs, though. We can use this to track that.
Yes, that would be great. A quick intro/summary of the steps, and a link. Something like “Testing resources are added like any other resource in your tool. For example, using SPM, do blah blah blah. See for more details. For Xcode, do …".
Eventually I discovered Bundle.module.load…, which works for both CLI and Xcode. Not sure that's the primary way to do it, but I think it’ll work across build environments and platforms.
