@mmerterden/multi-agent-pipeline 8.6.1 → 10.0.6

package/pipeline/skills/shared/external/swift-testing/references/testing-advanced.md

@@ -0,0 +1,123 @@
+# Advanced Testing Patterns
+
+Warning-severity issues, programmatic test cancellation, and image attachments for Swift Testing.
+
+## Contents
+
+- [Warning-Severity Issues](#warning-severity-issues)
+- [Programmatic Test Cancellation](#programmatic-test-cancellation)
+- [Exit Test Value Capturing](#exit-test-value-capturing)
+- [Image Attachments](#image-attachments)
+- [Version Gates](#version-gates)
+- [Proposal Reference](#proposal-reference)
+
+## Warning-Severity Issues
+
+ST-0013 adds a `severity` parameter to `Issue.record()` in Swift 6.3 / Xcode 26.4 and newer. Warnings are surfaced in test output but do not cause the test to fail.
+
+```swift
+@Test func dataIntegrity() {
+    let result = loadData()
+
+    // Hard failure  -  test fails
+    #expect(result.isValid)
+
+    // Warning  -  logged but test still passes
+    if result.processingTime > 2.0 {
+        Issue.record(
+            "Processing took \(result.processingTime)s  -  exceeds 2s target",
+            severity: .warning
+        )
+    }
+}
+```
+
+Use warnings for:
+- Performance regressions that aren't blocking
+- Deprecated code paths that still work
+- Non-critical data quality checks
+- Flaky conditions you want to track without failing CI
+
+## Programmatic Test Cancellation
+
+ST-0016 adds `try Test.cancel()` in Swift 6.3 / Xcode 26.4 and newer to stop a test from within without marking it as passed or failed. The test is recorded as "cancelled."
+
+```swift
+@Test func requiresNetwork() async throws {
+    guard NetworkMonitor.shared.isConnected else {
+        try Test.cancel("No network  -  skipping integration test")
+    }
+
+    let response = try await APIClient.shared.healthCheck()
+    #expect(response.status == .ok)
+}
+```
+
+Key differences from other mechanisms:
+- Throwing an error  -  marks the test as failed
+- `withKnownIssue`  -  marks a failure as expected (test still runs)
+- `try Test.cancel()`  -  marks the test as cancelled (neutral outcome, test stops)
+
+## Exit Test Value Capturing
+
+ST-0012 allows exit tests to capture values from the enclosing scope when using the Swift 6.3 compiler. Exit testing itself requires Swift 6.2 / Xcode 26.0 or newer and uses the `processExitsWith:` macros.
+
+When an exit-test body reads values from the parent process, correct the sample to use an explicit capture list and mention the Swift 6.3 compiler requirement. Captured values must conform to `Sendable` and `Codable`.
+
+```swift
+@Test func exitCodeValidation() async {
+    let expectedCode: Int32 = 42
+    await #expect(processExitsWith: .failure) { [expectedCode] in
+        exit(expectedCode)  // Can now capture `expectedCode`
+    }
+}
+```
+
+## Image Attachments
+
+ST-0014 adds image attachments in Swift 6.3 / Xcode 26.4 and newer. Import both `Testing` and the relevant UI framework, then record platform image values directly and specify `as:` when you need an explicit format.
+
+```swift
+import Testing
+import UIKit
+
+@Test func renderedOutput() async throws {
+    let view = ChartView(data: sampleData)
+    let renderer = UIGraphicsImageRenderer(size: CGSize(width: 400, height: 300))
+    let image = renderer.image { ctx in
+        view.drawHierarchy(in: view.bounds, afterScreenUpdates: true)
+    }
+
+    // Attach UIImage directly
+    Attachment.record(image, named: "chart-output", as: .png)
+}
+```
+
+Supported Apple-platform image types include:
+- `UIImage` on iOS, tvOS, visionOS, and watchOS when importing UIKit
+- `CGImage` when importing CoreGraphics
+- `CIImage` when importing CoreImage
+- `NSImage` on macOS when importing AppKit
+
+## Version Gates
+
+| Feature | Minimum toolchain / platform |
+|---|---|
+| Attachments API for standard attachable values | Swift 6.2 / Xcode 26.0 |
+| Exit testing with `processExitsWith:` | Swift 6.2 / Xcode 26.0; supported on macOS, Linux, FreeBSD, OpenBSD, and Windows runtime targets |
+| Exit-test capture lists | Swift 6.3 compiler |
+| `Issue.record(_:severity:)` warnings | Swift 6.3 / Xcode 26.4 |
+| `Test.cancel(_:)` | Swift 6.3 / Xcode 26.4 |
+| Image attachment recording | Swift 6.3 / Xcode 26.4 |
+
+Do not use exit tests for iOS, tvOS, or watchOS runtime targets. For iOS app code that needs fatal-path coverage, move the exit behavior behind a smaller pure Swift API, test the non-exiting branches directly, and reserve exit tests for a supported host/tool target.
+
+## Proposal Reference
+
+| Proposal | Feature |
+|---|---|
+| ST-0009 | Attachments API (`Attachment` type, `.record()`) |
+| ST-0012 | Exit test value capturing |
+| ST-0013 | Warning-severity issues (`Issue.record` with `severity:`) |
+| ST-0014 | Image attachments on Apple platforms (cross-import overlays) |
+| ST-0016 | Programmatic test cancellation (`try Test.cancel()`) |

package/pipeline/skills/shared/external/swift-testing/references/testing-patterns.md

@@ -5,18 +5,21 @@
 - Expectations and Requirements
 - Suite Organization
 - Parameterized Tests
+- Execution Model
 - Confirmation and Known Issues
 - Tags
 - TestScoping and Test Organization
+- XCTest Migration Patterns
 - Mocking and Test Doubles
 - Testable Architecture
 - Async and Concurrent Tests
-- XCTest UI Tests — Page Object Pattern
+- XCTest UI Tests  -  Page Object Pattern
 - Performance Testing
 - Snapshot Testing
 - Test Attachments
 - Exit Testing
 - Test File Organization
+- What to Test
 - Common Mistakes and Review Checklist
 
 ## Basic Tests and Traits
@@ -139,6 +142,26 @@ func currencySymbols(code: String, symbol: String) {
 
 Each argument combination runs as an independent test case reported separately.
 
+## Execution Model
+
+Swift Testing uses Swift Concurrency and runs tests in parallel by default. Treat every test as isolated work unless you explicitly serialize a scope.
+
+```swift
+@Suite(.serialized, .tags(.database))
+struct DatabaseTests {
+    @Test func insertsRecord() async throws { /* ... */ }
+    @Test func removesRecord() async throws { /* ... */ }
+}
+```
+
+Use `.serialized` when tests must not overlap because they touch shared external state like a keychain, database, singleton service, or filesystem location. It does not make unrelated tests outside the serialized scope run one-at-a-time.
+
+Important implications:
+- Each test gets its own suite instance.
+- Declaration order is not a contract.
+- If one logical workflow depends on previous state, keep that workflow inside one test.
+- Prefer isolated fixtures over shared mutable globals.
+
 ## Confirmation and Known Issues
 
 ### Confirmation (Async Event Testing)
@@ -208,33 +231,89 @@ extension Tag {
 func apiCallReturnsData() async throws { /* ... */ }
 ```
 
-Filter tests by tag in Xcode test plans or CLI (`swift test --filter tag:critical`).
+Filter tests by tag in Xcode test plans or CLI (tag-based filtering syntax varies by toolchain  -  verify for your Swift version).
 
 ## TestScoping and Test Organization
 
-`TestScoping` consolidates per-test setup/teardown into reusable fixtures:
+`TestScoping` consolidates per-test setup/teardown into reusable fixtures when attached through a custom trait:
 
 ```swift
-struct DatabaseFixture: TestScoping {
-    let db: TestDatabase
-
+struct DatabaseScope: TestTrait, SuiteTrait, TestScoping {
     func provideScope(
-        for test: Test, testCase: Test.Case?,
+        for test: Test,
+        testCase: Test.Case?,
         performing body: @Sendable () async throws -> Void
     ) async throws {
         let db = try await TestDatabase.create()
-        try await body()
-        try await db.destroy()
+        do {
+            try await body()
+            try await db.destroy()
+        } catch {
+            try? await db.destroy()
+            throw error
+        }
     }
 }
 
-// Use with @Test trait
-@Test(.tags(.database))
+extension Trait where Self == DatabaseScope {
+    static var databaseScope: Self { .init() }
+}
+
+@Test(.databaseScope, .tags(.database))
 func insertsRecord() async throws {
-    // DatabaseFixture.provideScope wraps this test
+    // Test runs inside DatabaseScope.provideScope
+}
+```
+
+## XCTest Migration Patterns
+
+Swift Testing tests are functions annotated with `@Test`; they do not need `XCTestCase`. Use the smallest shape that needs the fixture:
+
+```swift
+@Test func validatesTotal() {
+    #expect(Cart(items: [.sample]).total == 9.99)
+}
+
+@Suite("Checkout")
+struct CheckoutTests {
+    let calculator = PriceCalculator()
+
+    @Test func appliesDiscount() {
+        #expect(calculator.total(discount: .percent(10)) == 8.99)
+    }
+}
+
+@Suite("Shared Cache")
+actor CacheTests {
+    var cache = TestCache()
+
+    @Test func storesValue() async {
+        await cache.store("value", forKey: "key")
+        #expect(await cache.value(forKey: "key") == "value")
+    }
+}
+
+struct PureHelperTests {
+    @Test static func normalizesInput() {
+        #expect(normalize("  email@example.com ") == "email@example.com")
+    }
 }
 ```
 
+Common XCTest mappings:
+
+| XCTest | Swift Testing |
+|---|---|
+| `XCTAssertTrue(x)` / `XCTAssert(x)` | `#expect(x)` |
+| `XCTAssertFalse(x)` | `#expect(!x)` |
+| `XCTAssertEqual(a, b)` | `#expect(a == b)` |
+| `XCTAssertThrowsError(try f())` | `#expect(throws: (any Error).self) { try f() }` |
+| `XCTAssertNoThrow(try f())` | `#expect(throws: Never.self) { try f() }` |
+| `try XCTUnwrap(value)` | `try #require(value)` |
+| `XCTFail("message")` | `Issue.record("message")` |
+
+Convert `setUp` into isolated suite `init()` state. Avoid moving fixtures into singletons or shared globals; Swift Testing runs tests in parallel by default. Use actors or per-test fixtures for mutable test doubles, and use `.serialized` only when an external shared resource cannot be isolated.
+
 ## Mocking and Test Doubles
 
 Define testable boundaries with protocols:
@@ -245,10 +324,15 @@ protocol UserRepository: Sendable {
     func save(_ user: User) async throws
 }
 
-struct MockUserRepository: UserRepository {
+actor MockUserRepository: UserRepository {
     var users: [String: User] = [:]
-    var fetchError: Error?
-    var savedUsers: [User] = []
+    var fetchError: (any Error)?
+    private(set) var savedUsers: [User] = []
+
+    init(users: [String: User] = [:], fetchError: (any Error)? = nil) {
+        self.users = users
+        self.fetchError = fetchError
+    }
 
     func fetch(id: String) async throws -> User {
         if let error = fetchError { throw error }
@@ -256,14 +340,14 @@ struct MockUserRepository: UserRepository {
         return user
     }
 
-    mutating func save(_ user: User) async throws {
+    func save(_ user: User) async throws {
         savedUsers.append(user)
         users[user.id] = user
     }
 }
 ```
 
-**Pattern:** Mocks conform to protocols, never subclass concrete types. Store call counts and arguments for verification.
+**Pattern:** Mocks conform to protocols, never subclass concrete types. For parallel Swift Testing runs, keep mutable mock state isolated in an actor or another Sendable-safe fixture. Store call counts and arguments for verification behind that isolation boundary.
 
 ## Testable Architecture
 
@@ -274,9 +358,9 @@ Inject dependencies through initializers for testability:
 class ProfileViewModel {
     var user: User?
     var error: Error?
-    private let repository: UserRepository
+    private let repository: any UserRepository
 
-    init(repository: UserRepository) {
+    init(repository: any UserRepository) {
         self.repository = repository
     }
 
@@ -298,8 +382,7 @@ class ProfileViewModel {
 }
 
 @Test @MainActor func viewModelHandlesError() async {
-    var mock = MockUserRepository()
-    mock.fetchError = URLError(.notConnectedToInternet)
+    let mock = MockUserRepository(fetchError: URLError(.notConnectedToInternet))
     let vm = ProfileViewModel(repository: mock)
     await vm.load()
     #expect(vm.user == nil)
@@ -329,15 +412,14 @@ class ProfileViewModel {
 
 // Error path testing
 @Test func fetchThrowsOnNetworkError() async {
-    var mock = MockUserRepository()
-    mock.fetchError = URLError(.notConnectedToInternet)
+    let mock = MockUserRepository(fetchError: URLError(.notConnectedToInternet))
     #expect(throws: URLError.self) {
         try await mock.fetch(id: "1")
     }
 }
 ```
 
-## XCTest UI Tests — Page Object Pattern
+## XCTest UI Tests  -  Page Object Pattern
 
 Swift Testing does not support UI testing. Use XCTest with XCUITest for all UI tests.
 
@@ -398,11 +480,11 @@ class FeedPerformanceTests: XCTestCase {
 }
 ```
 
-Performance tests require XCTest — not available in Swift Testing.
+Performance tests require XCTest  -  not available in Swift Testing.
 
 ## Snapshot Testing
 
-Use swift-snapshot-testing (pointfreeco) for visual regression. Requires XCTest:
+Add Point-Free's `SnapshotTesting` package to the test target via Swift Package Manager, then use it for visual regression. Requires XCTest:
 
 ```swift
 import SnapshotTesting
@@ -434,23 +516,23 @@ Attach diagnostic data to test results for debugging failures:
 @Test func generateReport() async throws {
     let report = try generateReport()
     // Attach the output for later inspection
-    Attachment(report.data, named: "report.json").record()
+    Attachment.record(report.data, named: "report.json")
     #expect(report.isValid)
 }
 
 // Attach from a file URL
 @Test func processImage() async throws {
     let output = try processImage()
-    try await Attachment(contentsOf: output.url, named: "result.png")
-        .record()
+    let attachment = try await Attachment(contentsOf: output.url, named: "result.png")
+    Attachment.record(attachment)
 }
 ```
 
-Attachments support any `Attachable` type and images via `AttachableAsImage`.
+Attachments support standard `Attachable` values such as `Data`, `[UInt8]`, strings, and Encodable values when Foundation is imported. Image attachments require Swift 6.3 / Xcode 26.4 or newer and support platform image types such as `UIImage`, `CGImage`, `CIImage`, and `NSImage`; pass `as: .png` or another supported format when the filename should be explicit.
 
 ## Exit Testing
 
-Test code that calls `exit()`, `fatalError()`, or `preconditionFailure()`:
+Test code that calls `exit()`, `fatalError()`, or `preconditionFailure()`. Exit testing requires Swift 6.2 / Xcode 26.0 or newer and is supported on macOS, Linux, FreeBSD, OpenBSD, and Windows runtime targets, not iOS, tvOS, or watchOS:
 
 ```swift
 @Test func invalidInputCausesExit() async {
@@ -460,7 +542,7 @@ Test code that calls `exit()`, `fatalError()`, or `preconditionFailure()`:
 }
 ```
 
-Exit testing runs the closure in a subprocess. The test passes if the process exits with the expected status.
+Exit testing runs the closure in a subprocess. The test passes if the process exits with the expected status. Capturing values from the parent process in an exit-test capture list requires the Swift 6.3 compiler.
 
 ## Test File Organization
 
@@ -479,17 +561,61 @@ Name test files `<TypeUnderTest>Tests.swift`. Describe behavior in function name
 
 **Skip:** SwiftUI view body layout (use snapshots), simple property forwarding, Apple framework behavior, private methods (test through public API).
 
+## CustomTestStringConvertible
+
+When parameterized test arguments appear in test output, Swift Testing uses `String(describing:)` by default. Conform to `CustomTestStringConvertible` for better output:
+
+```swift
+enum Food: CaseIterable {
+    case paella, oden, ragu
+}
+
+extension Food: CustomTestStringConvertible {
+    var testDescription: String {
+        switch self {
+        case .paella: "paella valenciana"
+        case .oden: "おでん"
+        case .ragu: "ragù alla bolognese"
+        }
+    }
+}
+
+@Test(arguments: Food.allCases)
+func isDelicious(_ food: Food) { /* output shows custom descriptions */ }
+```
+
+Use this for any type passed as a parameterized test argument where the default description is unclear  -  especially enums, IDs, or model types.
+
+## Availability-Conditional Tests
+
+Use `@available` on test functions to run tests only on specific OS versions:
+
+```swift
+@Test
+@available(iOS 18, macOS 15, *)
+func usesNewAPI() async throws {
+    let result = try await NewFramework.process()
+    #expect(result.isValid)
+}
+```
+
+Swift Testing skips `@available`-gated tests when running on older OS versions. This replaces XCTest's `#available` guard + early return pattern.
+
+Do not put `@available` on a suite type or a type that contains a suite; Swift Testing requires suite types to always be available. Put availability gates on individual `@Test` functions instead.
+
 ## Common Mistakes and Review Checklist
 
 1. **Testing implementation, not behavior.** Test what the code does, not how.
 2. **No error path tests.** If a function can throw, test the throw path.
 3. **Flaky async tests.** Use `confirmation` with expected counts, not `sleep` calls.
-4. **Shared mutable state between tests.** Each test sets up its own state via `init()` in `@Suite`.
+4. **Shared mutable state between tests.** Each test sets up its own state via `init()` in `@Suite` or a fixture.
 5. **Missing accessibility identifiers in UI tests.** XCUITest queries rely on them.
 6. **Using `sleep` in tests.** Use `confirmation`, clock injection, or `withKnownIssue`.
 7. **Not testing cancellation.** If code supports `Task` cancellation, verify it cancels cleanly.
-8. **Mixing XCTest and Swift Testing in one file.** Keep them in separate files.
+8. **Unclear XCTest migration boundaries.** Apple allows XCTest and Swift Testing in one file during migration; prefer separate files when it keeps imports, ownership, and runner expectations clearer.
 9. **Non-Sendable test helpers shared across tests.** Ensure test helper types are Sendable when shared across concurrent test cases.
+10. **Assuming test order.** Parallel default execution means declaration order and suite nesting do not create a workflow.
+11. **Using `.serialized` as a dependency chain.** Serialized scopes avoid overlap; they do not pass state from one test to the next.
 
 ### Review Checklist
 
@@ -501,4 +627,6 @@ Name test files `<TypeUnderTest>Tests.swift`. Describe behavior in function name
 - [ ] Tags applied for filtering (`.critical`, `.slow`)
 - [ ] Mocks conform to protocols, not subclass concrete types
 - [ ] No shared mutable state between tests
+- [ ] Tests do not rely on declaration order or shared suite instances
+- [ ] `.serialized` is reserved for exclusive state, not workflow sequencing
 - [ ] Cancellation tested for cancellable async operations

package/pipeline/skills/shared/external/swift-testing-pro/SKILL.md

@@ -24,12 +24,12 @@ If doing partial work, load only the relevant reference files.
 
 - Target Swift 6.2 or later, using modern Swift concurrency.
 - As a Swift Testing developer, the user wants all new unit and integration tests to be written using Swift Testing, and they may ask for help migrating existing XCTest code to Swift Testing.
-- Swift Testing does *not* support UI tests – XCTest must be used there.
+- Swift Testing does *not* support UI tests - XCTest must be used there.
 - Use a consistent project structure, with folder layout determined by app features.
 
 Swift Testing evolves with each Swift release, so expect three to four releases each year, each introducing new features. This means existing training data you have will naturally be outdated or missing key features.
 
-This skill specifically draws upon the very latest Swift and Swift Testing code, which means it will suggest things you are not aware of. Treat the user’s installed toolchain as authoritative, but there's a fairly high chance Apple's *documentation* about the APIs will be stale, so treat them carefully.
+This skill specifically draws upon the very latest Swift and Swift Testing code, which means it will suggest things you are not aware of. Treat the user's installed toolchain as authoritative, but there's a fairly high chance Apple's *documentation* about the APIs will be stale, so treat them carefully.
 
 
 ## Output Format

package/pipeline/skills/shared/external/swift-testing-pro/references/async-tests.md

@@ -94,14 +94,14 @@ func workerRunsThreeTimes() async {
 }
 ```
 
-**Note:** `confirmation(expectedCount: 0)` is valid, and means “ensure the event we’re watching never happens.”
+**Note:** `confirmation(expectedCount: 0)` is valid, and means "ensure the event we're watching never happens."
 
 
 ## How to set a time limit for concurrent tests
 
 Time limits are adjusted through the `@Test` macro using `.timeLimit()`. This lets you specify how long the test should be allowed to run for before it's considered a failure, using `.minutes()` as appropriate.
 
-**Important:** Many agents strongly believe that you can `.seconds()` here. You cannot use `.seconds()` here – it’s `.minutes()` or nothing.
+**Important:** Many agents strongly believe that you can `.seconds()` here. You cannot use `.seconds()` here - it's `.minutes()` or nothing.
 
 For example, we could apply a 1-minute maximum runtime like this:
 
@@ -154,7 +154,7 @@ func loadNames() async {
 }
 ```
 
-Finally, test targets can have default actor isolation enabled, which might force all tests onto a specific actor – check for this carefully.
+Finally, test targets can have default actor isolation enabled, which might force all tests onto a specific actor - check for this carefully.
 
 
 ## Testing pre-concurrency code

package/pipeline/skills/shared/external/swift-testing-pro/references/core-rules.md

@@ -31,8 +31,8 @@ This guide provides core rules you must always follow to ensure you're making na
 - Parameterized tests are extremely powerful and allow tests to cover a wider range of ground without the code greatly expanding, so prefer them where possible. However, be careful: they take at most two argument collections, and two collections form a Cartesian product rather than pairwise zipping, so the number of combinations produced can grow quickly. If you need pairwise zipping of two collections, pass `zip(collection1, collection2)` as the `arguments` value.
 - Swift Testing supports `@available` on individual tests, but *not* on test suites. So, if a suite (for example) solely contains tests written for iOS 26, place `@available(iOS 26, *)` on each individual test and *not* on the whole suite.
 - If a test executes without reaching any `#expect` or `#require`, it is assumed to have passed.
-- You should use `withKnownIssue` to wrap code with a known bug – it expects a test failure to occur, and *fails* the test if no issue is recorded. Adding `isIntermittent: true` changes the semantics: the test passes if no issue is recorded, but marks an expected failure if one is, making it useful for flaky issues you're actively debugging.
-- Never use `!` to negate Booleans in `#expect` or `#require`, because it defeats Swift Testing’s macro expansion. So, `#expect(!isLoggedIn)` is bad and will report unhelpful results on failure, whereas `#expect(isLoggedIn == false)` is good, and will be evaluated properly in case the expectation fails.
+- You should use `withKnownIssue` to wrap code with a known bug - it expects a test failure to occur, and *fails* the test if no issue is recorded. Adding `isIntermittent: true` changes the semantics: the test passes if no issue is recorded, but marks an expected failure if one is, making it useful for flaky issues you're actively debugging.
+- Never use `!` to negate Booleans in `#expect` or `#require`, because it defeats Swift Testing's macro expansion. So, `#expect(!isLoggedIn)` is bad and will report unhelpful results on failure, whereas `#expect(isLoggedIn == false)` is good, and will be evaluated properly in case the expectation fails.
 
 Finally, use `@Tag` to create custom Swift Testing tags like this:
 

package/pipeline/skills/shared/external/swift-testing-pro/references/migrating-from-xctest.md

@@ -7,11 +7,11 @@ Most things in XCTest have a direct equivalent in Swift Testing:
 - `XCTAssertEqual(a, b)` maps to `#expect(a == b)`
 - `XCTAssertLessThan(a, b)` maps to `#expect(a < b)`
 - `XCTAssertThrowsError` maps to `#expect(throws:)`
-- `XCTUnwrap(optional)` maps to `try #require(optional)` – both unwrap or fail, but `#require` works with any Boolean condition too.
-- `XCTFail("message")` maps to `Issue.record("message")` – use this to manually record a test failure.
-- `XCTAssertIdentical(a, b)` maps to `#expect(a === b)` – for checking two references point to the same object instance.
+- `XCTUnwrap(optional)` maps to `try #require(optional)` - both unwrap or fail, but `#require` works with any Boolean condition too.
+- `XCTFail("message")` maps to `Issue.record("message")` - use this to manually record a test failure.
+- `XCTAssertIdentical(a, b)` maps to `#expect(a === b)` - for checking two references point to the same object instance.
 
-…and so on.
+...and so on.
 
 However, Swift Testing does *not* offer built-in float tolerance when checking if two floating-point values are *close enough* to be considered the same.
 
@@ -31,4 +31,4 @@ If you are tasked with converting XCTest code to Swift Testing, you should:
 1. Start by keeping the same broad structure: the same type names (just going from a class to a struct), and the same test methods (just removing `test` from the names and using `@Test` instead), switching from old-style assertions to new-style expectations.
 2. Look for places where parameterized tests can either cut down on test code or improve coverage.
 3. Add any appropriate `#require` checks at the start of tests, for preconditions.
-4. Finish by adding traits where appropriate – `.timeLimit()`, `.enabled(if:)`, `.tags()`, etc, to replace XCTest conventions such as skipping tests.
+4. Finish by adding traits where appropriate - `.timeLimit()`, `.enabled(if:)`, `.tags()`, etc, to replace XCTest conventions such as skipping tests.

package/pipeline/skills/shared/external/swift-testing-pro/references/new-features.md

@@ -150,7 +150,7 @@ Then apply it to tests:
 
 For multiple task local values, either nest `withValue()` calls inside a single scope, or create separate scopes and combine them: `@Test(.firstScope, .secondScope, .thirdScope)`. Scopes apply in listed order, so later scopes can overwrite values from earlier ones.
 
-Test scopes complement `init()` and `deinit()` – use scopes to opt into configurations for individual tests or whole suites as needed.
+Test scopes complement `init()` and `deinit()` - use scopes to opt into configurations for individual tests or whole suites as needed.
 
 
 ## Exit tests
@@ -181,7 +181,7 @@ To test this with Swift Testing, use `#expect(processExitsWith:)` to look for an
 }
 ```
 
-**Important:** This must be executed using `await` – behind the scenes this starts a dedicated process for that test, then suspends the test until that process completes and can be evaluated.
+**Important:** This must be executed using `await` - behind the scenes this starts a dedicated process for that test, then suspends the test until that process completes and can be evaluated.
 
 
 ## Attachments
@@ -269,7 +269,7 @@ func checkForSmokeTest() async throws {
 
 **Requires Swift 6.1 or later.**
 
-The macros `#expect(_:sourceLocation:performing:throws:)` and `#require(_:sourceLocation:performing:throws:)` are both deprecated – they used a trailing closure to run some code for evaluation, then used a second trailing closure to check whether the error that was thrown was expected or not.
+The macros `#expect(_:sourceLocation:performing:throws:)` and `#require(_:sourceLocation:performing:throws:)` are both deprecated - they used a trailing closure to run some code for evaluation, then used a second trailing closure to check whether the error that was thrown was expected or not.
 
 Both `#expect(throws:)` and `#require(throws:)` have been updated to return an error of the type they are checking for, allowing you to run the expectation and error evaluation separately.
 

package/pipeline/skills/shared/external/swift-testing-pro/references/writing-better-tests.md

@@ -29,11 +29,11 @@ And, if appropriate, concurrency tests.
 
 ## Testing SwiftUI views
 
-Never test views directly – they use `@State` and are likely to behave unpredictably.
+Never test views directly - they use `@State` and are likely to behave unpredictably.
 
 Instead, test view models or similar. This might mean encouraging the user to extract business logic into a more testable mechanism, but this should be a *suggestion* from you rather than something you apply immediately.
 
-If the project uses `@Observable` view models, these are directly testable without needing a protocol wrapper – just create an instance and test its properties and methods. For more help with SwiftUI, suggest the [SwiftUI Pro agent skill](https://github.com/twostraws/swiftui-agent-skill).
+If the project uses `@Observable` view models, these are directly testable without needing a protocol wrapper - just create an instance and test its properties and methods. For more help with SwiftUI, suggest the [SwiftUI Pro agent skill](https://github.com/twostraws/swiftui-agent-skill).
 
 
 ## Structuring tests
@@ -119,7 +119,7 @@ This same concept applies to other things: aim to control time, randomness, and
 
 Both `#expect` and `#require` evaluate a condition and fail the test if it's false. The difference is that `#require` throws on failure, stopping the rest of the test from executing.
 
-**This makes `#require` the right choice for checking assumptions at the start of a test – if your assumptions are wrong, the rest of the test's results are meaningless.**
+**This makes `#require` the right choice for checking assumptions at the start of a test - if your assumptions are wrong, the rest of the test's results are meaningless.**
 
 Using `#require` requires adding `throws` to your test method. For example, if your test depends on some setup being correct before the real assertion:
 
@@ -182,12 +182,12 @@ This approach gives fine-grained control: you can assert on the *specific* error
 An alternative is using `#expect(throws:)`. Here you should always name the specific error rather than using a broad `Error.self`:
 
 ```swift
-// Bad – passes for any error
+// Bad - passes for any error
 #expect(throws: Error.self) {
     try game.play()
 }
 
-// Good – asserts the exact error case
+// Good - asserts the exact error case
 #expect(throws: GameError.notInstalled) {
     try game.play()
 }