New constructor for envvar-based condition trait creation

[jerryjrchen]

The new condition trait constructor makes it easy to skip/unskip tests based on the presence of a specific environment variable.

Motivation:

A common* use case for environment variables is to enable or skip specific tests. More specifically, imagine you have a test plan that uses environment variables to adjust other test parameters, like I dunno, Address Sanitizer or something. Then some tests you have might not be compatible with that, so needs to be skipped with the ASan configuration. In that case, you could do:

@Test(.disabled(ifEnvironmentPresent:"ENABLE_ADDRESS_SANITIZER"))
func `Uses too much memory with ASan enabled` {
// ...
}

* Admittedly citation needed

Modifications:

Add new constructors that allow create condition traits that depend on environment variable contents. It does not attempt to inspect the value to determine if it is "truthy" or not.

Checklist:

• Code and documentation should follow the style of the Style Guide.
• [n/a] If public symbols are renamed or modified, DocC references should be updated.

Need to resolve the issue of thread safety with the envvar unit tests added here before merging.

Some alternative options/extensions to consider:

• Allow specifying multiple environment variables? Could use a variadic or something here to allow that, although maybe that is an exceedingly rare case.

  The disadvantage would be that it would be a little ambiguous if you need to match on "all" or "any" env variable with this approach. The current implementation has the advantage of being quite simple and probably meeting the majority of use cases.

• Check for truthy/falsy values for matching env vars? For example, 0/false is considered "falsy", everything else considered "truthy". Then enabled means the env var is present with a truthy value, and disabled means the env var is missing or present with a falsy value.

  The main disadvantage here is that this logic would be more complicated and perhaps more surprising to users of the condition trait.

[grynspan]

This is a lot of code when a developer can already write:

.enabled(if: getenv("ABC123") != nil)

What's the justification for this?

[grynspan]

See our existing tests that modify environment variables.

[grynspan]

These should probably be marked .hidden. We have infrastructure for testing fixture tests and verifying they are (or are not) run.

[grynspan]

A single environment variable is not "an environment" so we need to bikeshed this parameter label and name.

[grynspan]

.disabled(ifEnvironmentPresent: "ABC123")

Is slightly more characters to write than:

.disabled(if: getenv("ABC123") != nil)

And more-more after we bikeshed the label because it's probably going to say environmentVariable rather than environment.

😶

[jakepetroules]

Agree this is better handled outside Swift Testing. In part because clients may also have different means of reading the environment. For example in Swift Build we access the environment solely through task locals in order to allow mocking it in tests.