Yeah, technically Swift Testing today is capable of doing everything you want thanks to TestScoping, but this proposal can make things a little nicer.
And ServiceContext is a good example of how this proposal can do that. Right now swift-service-context vends a task local that others will want to bind in tests. Currently there are two ways to do that:
- Anyone that uses
ServiceContextdefines their own test trait for binding the task local in their tests. - Or, swift-service-context can create a whole new ServiceContextModuleTestSupport library that creates this trait a single time, and then anyone that wants to bind the task local in their tests will depend on this library.
Neither option is great. The first leads to a lot of duplication across different projects, and the second is extra code and documentation to maintain for the library author (also test support library docs can't link to the main library in DocC), and they have to educate their users about how to use the test support library. And every library that has a @TaskLocal will need to do this, and the docs for these traits are basically all identical.
So, if this proposal is accepted, anybody using swift-service-context can just do this:
@Suite(.taskLocal(ServiceContext.$current, …))
struct MySuite {
…
}
And the same goes for any task locals DistributedTracing introduces.