ST-0009: Attachments

Evolution Proposal Reviews
1

Hello Swift community,

The review of ST-0009 "Attachments" begins now and runs through Tuesday April 8, 2025. The proposal is available here:

swift-evolution/proposals/testing/0009-attachments.md at main · swiftlang/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When emailing the review manager directly, please keep the proposal link at the top of the message.

Trying it out

To try this feature out, add a dependency to the main branch of swift-testing to your project:

...
dependencies: [
   .package(url: "https://github.com/swiftlang/swift-testing.git", branch: "main"),
],
...

and to your test target:

.testTarget(...
    ...,
    dependencies: [
       ...,
       .product(name: "Testing", package: "swift-testing")
    ]

Finally, import Swift Testing using @_spi(Experimental)
So, instead of import Testing, use @_spi(Experimental) import Testing instead.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a
    change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar
    feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick
    reading, or an in-depth study?

More information about the Swift evolution process is available at

swift-evolution/process.md at main · swiftlang/swift-evolution · GitHub

Thank you for contributing to Swift!

Rachel Brindle

Review Manager

8 Likes
2

+1 like it very much.

I have nothing to add but my hope that this paves the way for UI Tests in Xcode to drop XCTest and use Swift Testing instead :wink:

2 Likes
3

Generally a +1 from me on the proposal. I have used various forms of testing in the past that would have benefited from attachments such as snapshot tests or unit tests that wanted to attach the logs.

We will also introduce a cross-import overlay with Foundation—that is, a tertiary module that is automatically imported when a test target imports both Foundation and Swift Testing—that includes additional conformances for Foundation types such as Data and URL and provides support for attaching values that also conform to Encodable or NSSecureCoding .

This section is the only thing that stood out to me. My understanding is that cross-import overlays are not an accepted proposal and currently just a pitch. While the functionality is present in the compiler itself they aren't exposed in any way through Swift PM. I'm personally a bit worried for a proposal to use an unreviewed feature. Additionally, what impact does this have when consuming Testing directly from the package or hypothetically moving Testing out of the toolchain in the future again and making it a package dependency?

4

Quotes are out-of-order:

This statement is partially incorrect. We worked with @beccadax to enable the feature when building test targets via Swift Package Manager (Xcode already implicitly supports cross-import overlays.) And when using Apple's fork of the Swift toolchain, cross-import overlays are always enabled. So this "just works" when you use Swift Testing from the toolchain. (modulo some incompatibilities with @_spi that will be resolved if/when the interface is approved and promoted to full API.)

If you add Swift Testing as a package dependency instead of using the toolchain's copy, you will need to manually import the cross-import overlay's module to use it. Resolving that constraint is beyond the scope of this proposal, as is a discussion about moving Swift Testing out of the toolchain. :slightly_smiling_face:

Edit: If we do move out of the toolchain in the future and are distributed as a package, we won't need a cross-import overlay anymore. We'll be able to just move the code directly into the main Testing module and guard any uses of Foundation with a package trait check.

That's understandable. In general, the cross-import overlay feature is not ready to be formally reviewed via the Swift Evolution process (although I'll have to defer to Becca on any specifics here.) However, because of Swift Testing's position in the overall stack, we can't publicly link to any modules other than the standard library (and underscored extensions thereto like _Concurrency). In particular, if we add Foundation to the public interface of the Testing module, Foundation won't be able to write unit tests using Swift Testing.

This problem does not affect the broader ecosystem (including third-party testing libraries) because, in general, components outside the toolchain can freely link to those in the toolchain (or to other packages).

1 Like
5

Thanks for the detailed reply. I agree that this is not blocking the proposal and your suggestion to use package traits if the package is consumed via the package manager sounds great.

1 Like