-
Couldn't load subscription status.
- Fork 125
Create a separate library containing a fallback event handler. #1280
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
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™".
|
@swift-ci test |
| <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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This value is not set if an attachment wasn't saved to disk already, so it should be optional in the schema.
|
@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
Minimal version of the changes in Jonathan's original PR here: swiftlang#1280 The new library is renamed to be "_TestingInterop" to more closely match its intended (and limited) purpose, but that's open to further discussion. This library will eventually be visible in the toolchain, and either testing library (Swift Testing or XCTest) will be able to use it to pass along unhandled issues to a test runner from the other framework, enabling interoperability.
Minimal version of the changes in Jonathan's original PR here: swiftlang#1280 The new library is renamed to be "_TestingInterop" to more closely match its intended (and limited) purpose, but that's open to further discussion. This library will eventually be visible in the toolchain, and either testing library (Swift Testing or XCTest) will be able to use it to pass along unhandled issues to a test runner from the other framework, enabling interoperability.
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: