Removal of string literal tag definitions

Hello everyone! One of the features of swift-testing is a test trait that allows associating a tag with a test suite or test function. Currently there are two ways to express this trait: symbolically or with a string literal. We are removing the string literal definition of tags because as we adopt swift-testing, we've found it to be more useful to have a consistent set of well-defined tags used throughout our code.

For more background on string literal tags check out Rethinking symbolic vs. string literal tags.

Problem

A test author can associate a tag with a test or suite using the .tags() trait, to which they pass an already defined tag or a string literal to the tag. It's confusing to figure out which tests have certain tags when they are defined with string literals.

Proposed solution

We are removing string literal tag definitions because we have found it more clear and useful to define a tag in a specific place in code and have all the tests with that tag refer to the already defined tag.

Now test authors will define tags symbolically.

Test authors who are currently using string literal tags can update their test definitions to use symbolic tags similar to the following:

// String literal tag
@Test(.tags("tagFoo")) func example() { }  
​
-> 
​
// Symbolic tag
extension Tag {
    @Tag static var tagFoo: Tag
}
​
@Test(.tags(.tagFoo)) func example() { }

Source compatibility

This change will be breaking for test authors who have already adopted string literal tag definitions in their test signatures.

7 Likes

Does it have to be mutually exclusive? There are benefits to using constants instead of copy-paste repetition, for sure, but they don't really apply in some cases (just like sometimes it's better to just use a literal inline in the code than dogmatically always define a named constant for it).

Can you clarify what you mean here?

The proposal says:

We are removing string literal tag definitions…

I'm asking why. Having more formal methods for defining them is fine, but the existing string literal support is useful too.

We recognize string literal tags can be useful, but we think the higher priority workflow that we want to emphasize and encourage is having symbolic tags. We think users will reach for them more often, and will appreciate having auto-completion help avoid errors. We see this as the higher-priority workflow, and since we are converging towards stable API and need to curate things, we're starting with symbolic tags only. Over time we can discuss more and consider evolving tags based on feedback.

my two cents here is that if swift-testing did not already have string literal tags, it wouldn’t be motivating enough to add support for string literals to the package. seeing as it is still in its version-series infancy, i think its developers should be aggressive in linting low-value features.

3 Likes