Create a separate library containing a fallback event handler. #1280
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR adds an experimental helper library that contains a hook function called the "fallback event handler". When Swift Testing posts an event such as "issue recorded", but Swift Testing itself isn't the running testing library (i.e. XCTest is actually running), it calls the fallback event handler and passes the event (JSON-encoded) to it. Because the hook function is exported from a separate library, XCTest can (in theory, anyway) set the fallback event handler to a function that decodes the JSON-encoded event and translates it into the corresponding XCTest event. Swift Testing sets the fallback event handler itself when it starts running so that, conversely, if a testing library such as XCTest were to generate an event and determine it isn't running, it could post that event to the same event handler and have Swift Testing pick it up and translate it into a Swift Testing event. So that if you have code that calls `#expect()` from within XCTest, or if you have code that calls `XCTAssert()`` from within Swift Testing, it'll "just work™".
grynspan
requested review from
stmontgomery,
briancroom,
suzannaratcliff and
jerryjrchen
as code owners
grynspan
added
enhancement
|
@swift-ci test |
grynspan
commented
Aug 20, 2025
| <attachment> ::= { | ||
| "path": <string>, ; the absolute path to the attachment on disk | ||
| ["path": <string>,] ; the absolute path to the attachment on disk if it has |
There was a problem hiding this comment.
This value is not set if an attachment wasn't saved to disk already, so it should be optional in the schema.
grynspan
commented
Aug 20, 2025
grynspan
commented
Aug 20, 2025
grynspan
commented
Aug 20, 2025
grynspan
commented
Aug 20, 2025
|
@swift-ci test |
1 similar comment
|
@swift-ci test |
|
@swift-ci test |
|
@swift-ci test |
|
@swift-ci test |
…ght to use the copy from the toolchain rather than rolling its own which other libraries won't know to link to
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds an experimental helper library that contains a hook function called the "fallback event handler". When Swift Testing posts an event such as "issue recorded", but Swift Testing itself isn't the running testing library (i.e. XCTest is actually running), it calls the fallback event handler and passes the event (JSON-encoded) to it.
Because the hook function is exported from a separate library, XCTest can (in theory, anyway) set the fallback event handler to a function that decodes the JSON-encoded event and translates it into the corresponding XCTest event.
Swift Testing sets the fallback event handler itself when it starts running so that, conversely, if a testing library such as XCTest were to generate an event and determine it isn't running, it could post that event to the same event handler and have Swift Testing pick it up and translate it into a Swift Testing event.
So that if you have code that calls
#expect()from within XCTest, or if you have code that callsXCTAssert()from within Swift Testing, it'll "just work™".Checklist: