[Review] ST-0022 Custom reflection during testing

Hello Swift Community!

The review of ST-0022 " Custom reflection during testing" starts now and runs through Tuesday, April 14th, 2026. The proposal is available here: swift-evolution/proposals/testing/0022-customtestreflectable.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 messaging 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"),
]

Then, add a target dependency to your test target:

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

Finally, import Swift Testing using @_spi(Experimental) import Testing.

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!

Maarten Engels

Review Manager

4 Likes

I am curious how we expect adoption of this feature to work out in practice. I assume most types that want to conform to this protocol live in targets or executableTargets. Those targets cannot easily import Testing since Testing is only available during test execution. We have run into this problem previously where packages are defining "test helper" targets that are only used when running tests; however, in this case I expect that the Testing usage here would proliferate outside of "test helper" targets. Do we expect developers to conditionally #if canImport(Testing) in their targets to add these conformances?

As with CustomTestStringConvertible, the conformances would be expected to live in a test target. If they rely on implementation details that are not visible in the test target (via @testable import or otherwise), developers can write something like:

extension MyType {
  package var customTestMirror: Mirror { ... }
}

And then just add the formal conformance in an (empty) extension in the test target.

And just for clarity, it doesn't have to be a .testTarget, right? A regular .target is fine if it's using the "test support target" pattern where you have a library shared by multiple test targets. The only thing that matters is that you don't put it into a dependency that gets linked into any production code.

Could we reflect that guidance in the proposal and the protocol documentation somewhere?

2 Likes

Yep, I'll make sure to discuss this approach when I write the prose documentation. We can add a note about it to the proposal text as well post-review.

2 Likes

Correct. I'm using "test target" in my above comments imprecisely to refer to both.

Right-o!

1 Like

ST-0022 has been accepted! Thanks everyone for participating!

1 Like