Skip to content
Agentmart
Submit a tool

modernize-tests

Modernize test suites to use modern Swift Testing features or migrate from XCTest.

Skill by guillevc

IndexedMIT
Write a review

Install

Works with Claude Code, Claude apps, Codex, Cursor, Gemini CLI, GitHub Copilot, VS Code, OpenCode, Goose, Windsurf. Read the repository before you give any tool access to your data.

npx agentmarket install skill/guillevc-modernize-tests

Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.

Get the weekly diff

The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.

We use your email only for this newsletter. Privacy

About

Modernize test suites to use modern Swift Testing features or migrate from XCTest.

Use cases: testing

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions

What this skill can do and what it asks for, from its SKILL.md. Checked Oct 25, 2026.

Tools
No tools found
Secrets
None asked for
Install scripts
None found

Network hosts it talks to 1

  • codeload.github.com · found in install command

Files it touches

  • ~/.claude/skills/modernize-tests

What's inside

Skill name
modernize-tests
Description
Modernize test suites to use modern Swift Testing features or migrate from XCTest.
License
MIT
Instructions
242 lines in SKILL.md · view on GitHub

Files (1)

  • SKILL.md

SKILL.md (first lines)

# Modernize Tests

Test modernization refers to two potential actions: migrating from XCTest to Swift Testing, and updating existing Swift Testing tests to use recommended patterns.

XCTests should be migrated to Swift Testing when possible. However, not all XCTests can be migrated to Swift Testing.
- UI tests (those that use XCUIAutomation) cannot be written with Swift Testing, and must remain XCTests.
- XCTests that use the `measure { ... }` family of APIs for performance measurement cannot be migrated. However, other test methods within an XCTestCase that do not use XCTest performance APIs can be migrated.

## Migration Reference

### Imports

Replace `import XCTest` with `import Testing`. A file can import both if it contains mixed test content during incremental migration.

When removing `import XCTest`, check whether the file uses Foundation types (URL, CharacterSet, ProcessInfo, Data, etc.). XCTest re-exports Foundation, so add `import Foundation` if needed.

### Test Classes to Suites

Remove `XCTestCase` inheritance. Prefer structs over classes:

- `final class FoodTruckTests: XCTestCase { ... }` -> `struct FoodTruckTests { ... }`

### Move setUp/tearDown code to init/deinit

Replace `override func setUp()` with `init()` (can be `async throws`). Replace `override func tearDown()` with `deinit`. If `deinit` is needed, use
`actor` or `final class` instead of `struct` (since structs have no `deinit`). Change stored properties to not use implicitly-unwrapped optional
types, and move their initial assignment from `setUp` to either be initialized inline or, if the initialization is complex, in an initializer.

```
struct MyTests {
    var fixture = Fixture()
    mutating func `Fixture behaves as expected`() {
        #expect(fixture.doSomething())
    }
}
```

Avoid pulling instance variables into function bodies; this can cause noise. Swift Testing reinvokes the initializer fresh before each test runs.
If the test mutates an instance variable with value semantics, you may need to mark the test function `mutating`.

### Test Methods

Replace the `test` name prefix with the `@Test` attribute. If the resulting test name includes multiple camelCase words,
use a raw identifier with the test name in sentence case.

- `func testEngineDoesNotStall() { ... }` -> `@Test func `Engine does not stall`() { ... }`
- `func testIgnition() { ... }` -> `@Test func ignition() { ... }`

Test functions can be `async`, `throws`, or `async throws`, and can be isolated to a global actor with `@MainActor`.

### Assertions to Expectations

When migrating a test from XCTest to Swift Testing, apply these mappings:

`XCTAssert(x)`, `XCTAssertTrue(x)` -> `#expect(x)`
`XCTAssertFalse(x)` -> `#expect(!x)`
`XCTAssertNil(x)` -> `#expect(x == nil)`
`XCTAssertNotNil(x)` -> `#expect(x != nil)`
`XCTAssertEqual(x, y)` -> `#expect(x == y)`
`XCTAssertNotEqual(x, y)` -> `#expect(x != y)`
`XCTAssertIdentical(x, y)` -> `#expect(x === y)`
`XCTAssertNotIdentical(x, y)` -> `#expect(x !== y)`
`XCTAssertGreaterThan(x, y)` -> `#expect(x > y)`
`XCTAssertGreaterThanOrEqual(x, y)` -> `#expect(x >= y)`
`XCTAssertLessThanOrEqual(x, y)` -> `#expect(x <= y)`
`XCTAssertLessThan(x, y)` -> `#expect(x < y)`
`try XCTUnwrap(x)` -> `try #require(x)`

There is no direct equivalent for `XCTAssertEqual(_:_:accuracy:)`; use floating point math directly.

### Errors

When the error type is `Equatable` and the exact value is known, prefer to check the specific error value.

```
XCTAssertThrowsError(try f())
```
->
```
#expect(throws: (any Error).self) {
    try f()
}
```

```
XCTAssertThrowsError(try f()) { error in
    XCTAssertEqual(error, specificError)
}
```
->
```
#expect(throws: specificError) {
    try f()
}
```

```
XCTAssertThrowsError(try f()) { error in
    // Check error
}
```
->
```
let error = #expect(throws: (any Error).self) {
    try f()
}
// Check error
```

```
XCTAssertNoThrow(try f())
```
->
```
#expect(throws: Never.self) {
    try f()
}
```

### continueAfterFailure

From guillevc/skills, MIT.

More from guillevc/skills

Signals

Stars
0
Forks
0
Open issues
0
Last commit (this folder)
Oct 3, 2026 (25 days ago)

From GitHub (fetched Oct 24, 2026).

Details

License
MIT
First seen
Oct 24, 2026
Last checked
Oct 24, 2026

More from guillevc

Cite this page

modernize-tests skill. Agent Mart. https://agentmart.dev/skills/guillevc-modernize-tests (last updated 2026-10-24)