Add a public initializer for Testing.Test

[younata]

Description

I'm in the process of creating a BDD-style DSL on top of Swift Testing (Quick/Quick#1292), and I'm looking at creating Testing.Tests. I could use Testing.Test.__function, but that's explicitly discouraged (though that's definitely what I'll be using for the time being).

I'd like for the Test struct initializers to be made public, so that I have an explicitly supported way to generate Test objects.

[Uncommon]

I think it would also be useful to have a public API for creating suites. Currently, Test.isSuite is computed based on the value of containingTypeInfo, so the concept of a suite is directly and exclusively connected to actually using the @Suite macro.

On the whole, there seems to be a lot of tight coupling between macros and test implementation. Are there plans to loosen this up?

[grynspan]

I think it would also be useful to have a public API for creating suites.

Suites are tests from the point of view of Swift Testing. It's just a question of whether there's an associated sequence of Test.Case instances that makes it a test function instead. (This is in part an artifact of earlier stages of Swift Testing's development, and in part a simplification to let us have heterogenous collections of test content.)

On the whole, there seems to be a lot of tight coupling between macros and test implementation. Are there plans to loosen this up?

Not in the way you're thinking. Very broadly, the plan is to allow third-party libraries to define their own test content records that can either be picked up directly by Swift Testing or discovered at runtime by some other library that runs as a peer of Swift Testing (and utilizes some, but not all, of its API.)

We haven't fully fleshed out this plan yet, but parts of it have landed on main. See for example #893, #880, and #928.

[grynspan]

Tracked internally as rdar://131059714.

@younata, let's find time to discuss this in the workgroup.