I need a replacement for `XCTContext.runActivity(named:)`

[uhooi]

Description

~~SSIA~~

I want to name each process in the test function. I do not want to run it in the main thread.

Expected behavior

No response

Actual behavior

No response

Steps to reproduce

No response

swift-testing version/commit hash

70f5963

Swift & OS version (output of swift --version && uname -a)

$ swift --version && uname -a
swift-driver version: 1.87.1 Apple Swift version 5.9 (swiftlang-5.9.0.128.108 clang-1500.0.40.1)
Target: arm64-apple-macosx13.0
Darwin uhooinoMacBook-Air.local 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul  5 22:22:52 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T8103 arm64

[uhooi]

A runtime error occurs.

[grynspan]

Thank you for filing! It would be very helpful if, instead of writing "SSIA", you could give us more information about the problem you're seeing. In this case, please tell us what you need runActivity() for so that we can better-understand your use case and figure out how to prioritize this request.

Regarding the error you're seeing: XCTContext.runActivity(named:) is main-thread-bound, but test functions in swift-testing run on arbitrary threads. You can resolve this runtime issue by adding @MainActor to the test function declaration.

[uhooi]

@grynspan Thanks for the reply! I was short on words. I added it, please take a look.

[grynspan]

Tracked internally as rdar://88647458.

[myihsan]

Wrapping those activities in a test suite (e.g. a struct) seems sufficient to me. Are there any other reasons you need from runActivity(named:block:)?

[grynspan]

A common use case for XCTActivity is to divide longer tests up into subtasks.

[myihsan]

I see. The purpose is not to group tests, but to divide a test up into subtasks that run serially and share variables👍

[grynspan]

Basically, yeah. :)

Whether or not they run serially is its own question and something we have to answer if/when we design this API for Swift Testing. XCTest is originally Objective-C-based and very serialized, but Swift Testing is much more parallel and leverages Swift concurrency. We don't want to limit test authors' ability to use Swift concurrency when writing tests if we can avoid it.