{"id":47271,"date":"2025-04-01T16:23:46","date_gmt":"2025-04-01T20:23:46","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=47271"},"modified":"2025-07-14T13:46:08","modified_gmt":"2025-07-14T17:46:08","slug":"swift-testing-test-scoping-traits","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/04\/01\/swift-testing-test-scoping-traits\/","title":{"rendered":"Swift Testing: Test Scoping Traits"},"content":{"rendered":"

Holly Borla<\/a>:<\/p>\n

\n

Swift 6.1 enables custom Swift Testing traits to perform logic before or after tests run in order to share set-up or tear-down logic. If you write a custom trait type which conforms to the new TestScoping<\/code> protocol, you can implement a method to customize the scope in which each test or suite the trait is applied to will execute. For example, you could implement a trait which binds a task local value to a mocked resource:<\/p>\n

struct MockAPICredentialsTrait: TestTrait, TestScoping {\n  func provideScope(for test: Test, testCase: Test.Case?, performing function: @Sendable () async throws -> Void) async throws {\n    let mockCredentials = APICredentials(apiKey: \"fake\")\n    try await APICredentials.$current.withValue(mockCredentials) {\n      try await function()\n    }\n  }\n}\n\nextension Trait where Self == MockAPICredentialsTrait {\n  static var mockAPICredentials: Self { Self() }\n}\n\n@Test(.mockAPICredentials)\nfunc example() {\n  \/\/ Validate API usage, referencing `APICredentials.current`...\n}<\/pre>\n<\/blockquote>\n
Because task locals cannot be separated into set-up and tear-down portions, they were previously only usable in Swift Testing if you repeated them within each test function. TestScoping<\/code> gets rid of the indentation that entails and can also be applied at the suite level, so you don’t have to repeat it for each test. It’s great to have this functionality, though I think the implementation via traits feels a bit convoluted compared with XCTest’s invokeTest()<\/code>.<\/p>\n\n
ST-0007<\/a>:<\/p>\n
Some test authors have expressed interest in allowing custom traits to access\nthe instance of a suite type for @Test<\/code> instance methods, so the trait could\ninspect or mutate the instance. Currently, only instance-level members of a\nsuite type (including init<\/code>, deinit<\/code>, and the test function itself) can access\nself<\/code>, so this would grant traits applied to an instance test method access to\nthe instance as well. This is certainly interesting, but poses several technical\nchallenges that puts it out of scope of this proposal.<\/p><\/blockquote>\n
It seems like a major limitation that any code factored out in this way can’t access properties or helper functions in the type that contains the test.<\/p>\n\n
Some reviewers of this proposal pointed out that the hypothetical usage example shown earlier involving setting a task local value while a test is executing will likely become a common use of these APIs. To streamline that pattern, it would be very natural to add a built-in trait type which facilitates this. I have prototyped this idea and plan to add it once this new trait functionality lands.<\/p><\/blockquote>\n\n
Previously:<\/p>\n