Closed mattmassicotte closed 3 days ago
It is intentional that the function does not block the caller waiting for work to complete. Such work is generally best handled using Swift concurrency instead. Watch Go further with Swift Testing where we talk about this sort of pattern.
I agree! But as it stands, this API is actually quite easy to use wrong like I just did.
I think an overload allow this to just work transparently. What would the downside be?
public func confirmation<R>(_ comment: Testing.Comment? = nil, expectedCount: Int = 1, fileID: String = #fileID, filePath: String = #filePath, line: Int = #line, column: Int = #column, _ body: (Testing.Confirmation) throws -> R) async rethrows -> R {
try await confirmation(comment, expectedCount: expectedCount, fileID: fileID, filePath: filePath, line: line, column: column) { thing in
try await withCheckedThrowingContinuation { continuation in
let result = Result(catching: { try body(thing) })
continuation.resume(with: result)
}
}
}
Edit: thinking on this more, I guess that won't work outside of some trivial cases. Oh well!
In the video, we discuss this exact pattern. 🙂
Next you're going to ask me to understand all the tools I try to use! 😉
Yes, but only out of love. 🙃
Description
I'm a beginner! I was trying to migrate over some XCTest-based code, and got tripped up by how
confirmation
works.I get it, and it makes sense. It's just different from how
XCTests
'sfulfillment
API works.Expected behavior
I wonder if it would be possible to maybe make an non-async overload that waits for the expected number of confirmations?
Actual behavior
No response
Steps to reproduce
No response
swift-testing version/commit hash
No response
Swift & OS version (output of
swift --version ; uname -a
)