Allow evaluating `ConditionTrait` programmatically

[Uncommon]

Description

I'm working on a testing library for writing structured tests like RSpec or Quick, with the intention of making it compatible with Swift Testing and XCTest rather than being a stand-alone framework. Right now I'm looking into whether I can use Swift Testing traits in my library's test elements; being able to just re-use existing traits could be really cool.

At first glance it was promising - Bug for example just contains the properties describing the bug, and then conforms to TestTrait via extension, making it easy to also use for other purposes.

But then there's ConditionTrait, where the Kind enum and kind property are not public, and the logic for evaluating the condition happens in prepare(for:) even though that method doesn't use the given test object. Is there a reason these elements are hidden? Or could they be made public, and the evaluation logic extracted to a separate function? Just the latter would probably be sufficient.

Expected behavior

ContitionTrait can be used/evaluated directly

Actual behavior

Evaluation logic is inaccessible because of non-public members

Steps to reproduce

No response

swift-testing version/commit hash

No response

Swift & OS version (output of swift --version && uname -a)

No response

[grynspan]

Kind/kind are simply implementation details of the type and do not need to be made public for the type to be usable.

What specifically do you need them for? Are you trying to create your own variations of ConditionTrait? You can create a custom factory function for that. For instance, if you want a condition trait that skips a test when the sky is blue:

extension Trait where Self == ConditionTrait {
  static var disabledIfSkyIsBlue: Self {
    .disabled(if: Earth.current.sky.color == .blue)
  }
}

[Uncommon]

Mainly I want to evaluate the condition without having to give it a Test (which it doesn't really need anyway), so that I can use it in the test elements of my library. I could do that if I had access to kind, or if there were a method that just gave me a true/false result.

[grynspan]

Yeah sounds to me like what you really want is something like func evaluate() async throws -> Bool. Does that sound right?

[Uncommon]

Yes, exactly.

To give more context about what I have in mind, a test body using my library can look like below, where Describe, BeforeAny, and It are types used by a result builder:

Describe("Some feature") {
    BeforeAny {
        // do some setup
    }
    BeforeAny(.enabled(if: /* some check */)) {
        // condition-specific setup
    }
    It("behaves correctly") {
        // test some things
    }
    It("does more things", .projectSpecificTrait) {
        // other tests
    }
}

So I'm hoping to use Swift Testing traits directly there. It seems potentially useful, for example, if .projectSpecificTrait is some trait I have defined in my project that can be used in both regular @Test tests and in the result-builder based tests.

[grynspan]

It seems reasonable to me to add such a function to the trait. As new API, the community would need an opportunity to review it. If you'd like to put together a PR and draft proposal, I don't see why we couldn't shepherd it through the forums for the next Swift release (6.1 or 6.2.)

[Uncommon]

Is there a template for a draft proposal? Or is it part of the pull request?

[grynspan]

You can start with the template here. Since this API change would be small, we can do a single PR with the proposal and implementation. When the proposal is ready, open a PR and start a thread on the Swift Forums under the swift-testing topic titled [Pitch] Your Title Here with a link back to the PR.

[Uncommon]

Should I use that template in the PR description? Or add it to Documentation/Proposals as a numbered proposal?

[grynspan]

We'll assign a number later in the process. Copy the template to a new file and name it appropriately. Use NNNN for the number for now.