ST-0013: Test Issue Warnings

Hello Swift community,

The review of ST-0013 "Test Issue Warnings" begins now and runs through Wednesday July 23, 2025. The proposal is available here:

swift-evolution/proposals/testing/0013-issue-severity-warning.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 enable-severity branch of the proposals author's fork of swift-testing to your package:

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

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.

You can now issue warnings in your tests:

@Test func exampleRecordWarning() {
    Issue.record("My warning message", severity: .warning)
}

Please note: this implementation makes it possible to emit the warnings in the cli output. However, at this time VSCode and non-beta versions of Xcode interpret warnings as test failures. So if you want to try this feature, you should rely on the cli.

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

6 Likes

I first thought that isFailure can be set directly, which would be weird. Maybe it's only me, but I think we could mention explicitly that this is a computed property.

Additionally I think that the record function's doc should also be updated from "Record an issue when a running test fails unexpectedly.", because with this change recording an issue doesn't mean that the test failed as well.

I think that the parameter doc of the severity input argument could also be more informative. "/// - severity: The severity of the issue." However I get that people will probably try it out by hitting a dot and seeing the docs of warning and error cases, which are really nicely documented.

I generally like the idea of introducing severity a lot based on the examples, thanks for the work. However I'm also afraid that people will abuse it the same way they abuse withKnownIssue and .disabled, but there's not much we can do about it.

2 Likes

Hi Ákos,

The first time I heard about this pitch, this was my concern as well. But in the end I believe this falls on the responsibility of the devs themselves. And even without this feature, there are enough other ways of 'gaming' tests.

4 Likes

This is really good feedback! Thank you!

Here are some updates:

3 Likes

Hi everyone,

We’ve got a couple of more days to go for this review. :alarm_clock:

If you want to give your feedback, there is still time to do so.

KR Maarten

ST-0013 has been accepted.

2 Likes