Introduce conditional trait that support "all must be met" and an "any must be met" to enable the test

[bkhouri]

Motivation

As a test case author, I want to explicitly enable, or disable, a test when:

• all conditional traits evaluate to true
• any conditional training evaluate to true

---

I always prefer explicit vs implicit. Take the following example

@Test(
   .enabled(if: conditionA),
   .enabled(if: conditionB),
)
func myTest() {
   // test implementation
}

It is unclear by ready the code whether the various conditions are || (OR-ed), or whether they are && (AND-ed). A developer must be aware of Swift Testing behaviour to know when the test will be enabled or disabled.

Proposed solution

One option is to introduce a .any and .all traits, that would accept a list of traits, or any number of traits.

Consider the following, which is more explicit. In the first, conditionA && conditionB must be true to enable the test, while the conditionA || conditionB must be true to enable the second test

@Test(
    .all(
        .enabled(if: conditionA),
        .enabled(if: conditionB),
    )
)
func myTestBothConditionsMustBeTrue() {
    // test implementation
}

@Test(
    .any(
        .enabled(if: conditionA),
        .enabled(if: conditionB),
    )
)
func myTestAnyConditionMustBeTrue() {
    // test implementation
}

The .any and .all become especially useful when custom condition traits are added, where using the single .enabled(if: condition) is more challenging.

extension Trait where Self == Testing.ConditionTrait {
    public static var enableOnlyOnMacOS: Self {
        enabled(if: isMacOS(), "Test is only supported on MacOS")
    }

    public static var enableIfRealSigningIdentityTestEnabled: Self {
        enabled(if: isRealSigningIdentityTestEnabled(), "Test only enabled during real signing indentity")
    }

    public static func enableIfEnvVarSet(_ envVarName: String) -> Self {
        let envKey = EnvironmentKey(envVarName)
        return enabled(
            if: isEnvironmentVariableSet(envKey),
            "'\(envVarName)' env var is not set"
        )
    }
}

@Test (
    .all(
        .enableOnlyOnMacOS,
        .enableIfRealSigningIdentityTestEnabled,
        .enableIfEnvVarSet("MY_ENV_VARIABLE"),
    )
)
funct myTest() {
}

Alternatives considered

I'm open to other solution

Additional information

No response

[grynspan]

Tracked internally as rdar://136052793.

[grynspan]

I suspect we would probably implement this in terms of standard Boolean operators, not a bespoke DSL.

[hrayatnia]

@bkhouri @grynspan I like to take a lead on this issue. Before I start coding, I came up with a rough idea to ask for your opinion and then I will implement the rest of it.

extension Trait where Self == ConditionTrait {
    static func any(
        _ traits: ConditionTrait...,
        comment: Comment? = nil,
        sourceLocation: SourceLocation = #_sourceLocation
    ) -> ConditionTrait {
        Self(kind: .conditional {
          try await traits._asyncContains { try await $0.evaluate() }
        }, comments: Array(comment), sourceLocation: sourceLocation)
    }
    
    static func all(
        _ traits: ConditionTrait...,
        comment: Comment? = nil,
        sourceLocation: SourceLocation = #_sourceLocation
    ) -> ConditionTrait {
        Self(kind: .conditional {
          try await traits._asyncAllSatisfy { try await $0.evaluate() }
        }, comments: Array(comment), sourceLocation: sourceLocation)
    }
}

extension Sequence where Element == ConditionTrait {
  fileprivate func _asyncAllSatisfy(_ predicate: @escaping (Element) async throws -> Bool) async throws -> Bool {
          for element in self {
              if !(try await predicate(element)) {
                  return false
              }
          }
          return true
      }
  
  fileprivate func _asyncContains(where predicate: @escaping (Element) async throws -> Bool) async throws -> Bool {
          for element in self {
              if try await predicate(element) {
                  return true
              }
          }
          return false
      }
}

@Test("Sample", .all(.any(.enabled, .enabled), .all(.enabled,.enabled)), .enabled)
func testSample() async throws {
    ...
}

[grynspan]

My thinking here was that we would implement || and && operators that would compose multiple instances of ConditionTrait into compound ones (with additional implementation details inside the type to support compound operations without losing track of which specific trait caused a test to be skipped.)

Then you'd be able to write something like:

@Test(.enabled(if: abc123) || .enabled(if: def456))

What makes this somewhat more complicated (regardless of how we spell the operations) is that .disabled(if: x), which is effectively identical to .enabled(if: !x), may not clearly compose. For instance, .disabled(if: x) || .disabled(if: y) equates to .enabled(if: !x) || .enabled(if: !y) whereas you probably meant it to be .enabled(if: !x) && .enabled(if: !y).

To solve that, we may need to teach the operator implementations to treat .enabled and .disabled differently, which is feasible but adds more complexity to the overall implementation.

[hrayatnia]

@grynspan I completely agree that preserving correct information is essential. However, the example logic doesn’t seem accurate.

According to De Morgan’s laws, the correct transformation should be:

.disabled(if: x) || .disabled(if: y) == !(.enabled(if: x) && .enabled(if: y))

.enabled(if: !x) && .enabled(if: !y) == !(.disabled(if: x) || .disabled(if: y))

In abstract terms, the pseudo-code representation would look like this:

extension Trait where Self == ConditionTrait {
    
    static func &&(lhs: Self, rhs: Self) -> Self {
        Self(kind: .conditional {
            let l = try await lhs.evaluate()
            let r = try await rhs.evaluate()
            return l && r
        })
    }
    
    static func ||(lhs: Self, rhs: Self) -> Self {
        Self(kind: .conditional {
            let l = try await lhs.evaluate()
            let r = try await rhs.evaluate()
            return l || r
        })
    }
    
    static prefix func !(lhs: Self) -> Self {
        Self(kind: .conditional {
            let l = try await lhs.evaluate()
            return !l
        })
    }
}

That said, I recognize that this approach isn't optimized—it introduces unnecessary overhead without simplifying the logic. I'll work on a more efficient solution.

[grynspan]

That's not quite how these operators combine today if you just use them within a single trait, and I suspect that could be problematic. For instance:

.disabled(if: x) || .disabled(if: y)

Should probably be equivalent to:

.disabled(if: x || y)
// i.e.
.enabled(if: !(x || y))

Not to:

.enabled(if: !(x && y))

[hrayatnia]

Correct me if I'm wrong, the expected end result should compose/merge logics instead of seeing like a boolean value? In other words (as you said), instead of .disabled(if: x) || .disabled(if: y) == .enabled(if: !(x && y)) it should be .disabled(if: x) || .disabled(if: y) == .disabled(if: x || y) == .enabled(if: !(x || y)) right?

If that’s not the case, the suggested logic interprets it as a boolean-like value (with ExpressibleByBooleanLiteral) and all nine fundamental laws for conjunction and disjunction applies to it.

[grynspan]

Right, my gut sense is that .disabled(if: x) || .disabled(if: y) and .disabled(if: x || y) should evaluate to the same result (regardless of how we actually spell the symbols, using functions or operators.)

Does that make sense to you?

[hrayatnia]

Yes, it does, thanks for sharing that. It’s more of a grouping strategy rather than being a separation of logic.

Like .disable(if: Sensory.allCases, operator: ||, validate: \.isAvailable) should be equal to .disable(if: Sensory.camera.isAvailable) || .disable(if: Sensory.gps.isAvailable) || ... (or any other way / symbol for strategic grouping/composing/chaining/merging (for this specific issue grouping)).