Add a property to Test.Case to get the values of its arguments.#1350
Add a property to Test.Case to get the values of its arguments.#1350
Test.Case to get the values of its arguments.#1350Conversation
This PR adds an experimental property to `Test.Case` to allow callers to get the
test case's arguments as a type-erased array. For example:
```swift
if let testCase = Test.Case.current {
for value in testCase.argumentValues {
print("\(value): \(type(of: value))")
}
}
```
We already have an `arguments` property of a type that we do not intend to make
API, so the new property is named `argumentValues` pending any of SPI renaming.
| /// is the empty array. | ||
| @_spi(Experimental) | ||
| @_unavailableInEmbedded | ||
| public var argumentValues: [any Sendable] { |
There was a problem hiding this comment.
Can you add a unit test for this new property?
|
I know this is just an SPI at the moment but assuming the intention is to advance it to a public API, I'm interested in discussing the merits of exposing just this one property vs. exposing the backing Of course, nothing prevents us from pursuing both; they could complement each other. Said a different way, I'm not certain yet whether I agree with this statement from the PR description (emphasis mine):
I think we should consider both ideas, and that could take place during an API pitch thread. |
The comment is more to the point that I couldn't go and name the new property |
|
In any event I'm also fine leaving this specific PR on the table. I think there's value in allowing these values to be accessible but I don't feel too strongly about the precise shape of the API we would add. Fortunately the values are all constrained to |
This PR adds an experimental property to
Test.Caseto allow callers to get the test case's arguments as a type-erased array. For example:We already have an
argumentsproperty of a type that we do not intend to make API, so the new property is namedargumentValuespending any SPI renaming.Checklist: