Is there a way to modify the messages that are logged for issues while still allowing the user to use the usual #expect etc macros?
What I'm working on is an RSpec-like describe/context/it library, and I want to include the spec description in any failure messages.
I'm trying to make it compatible with both XCTest and Swift Testing. For XCTest, I customize the messages by using a subclass of XCTestCase that overrides record(_:) which works pretty straightforwardly.
I saw the new Issue.Kind work being done, but that doesn't seem like what I'm looking for - I want to modify the existing kids of issues, not log a new kind.
Currently I'm settling for customizing the issue logging, but ideally what I want to do is create a separate Test for each "it" element. Unfortunately customizing test discovery seems much less doable with the current API. It is tantalizing, though, since test suites can be nested, which seems like a good match for the hierarchical nature of the describe/context elements I'm trying to create.
Current code is here, very much a work in progress :)
The specific messages we emit for issue kinds produced by Swift Testing aren't meant to be customizable in the way you're describing. (You can add additional comments to an issue.) Our intent here is to allow third-party tools/library authors to use a custom issue kind (i.e. what you linked to above) when they need to present something distinct to the user.
It's not really clear to me what it would look like to make issue strings customizable. Can you share a more concrete example of what you want to do and where the constraints are?
Would it be fair to rephrase the question as something like "how can I add additional state to issues when they are recorded?" Because that probably has more solutions than a hook in Issue.description, ya know?
Test discovery is an area of ongoing research for us. Right now test discovery is actually pretty wonky under the covers, but we're designing a new "stable" solution that would be possible for you to hook into to provide additional tests, if you wanted. See here for part of the prototyping work.
Yes, that's probably better. I guess I'm coming from the perspective of what was possible from XCTest. So what would be the answer to this version of the question?
There's probably loads of answers! But I suspect we'd want to leverage the equivalent of XCTest "activities" here. We don't know exactly what that API will look like yet, but (hypothesizing here) I imagine they'd carry additional state to apply to events that occur within their scopes. So (hypothesizing again!) something like:
runActivity(metadata: ["RSpecDescription": ...]) { activity in
#expect(a == b)
...
}
Again, we haven't designed activities for Swift Testing yet, so please don't take the syntax above as a serious design proposal.
I know it's not the answer you were hoping for, but no—not in Swift 6.0. I would encourage you to comment on the GitHub issue for activities support and explain your use case there (or just link to this thread, I ain't that picky.)
