Swift Testingへの移行

Swift Testingへの移行

テストフレームワークの相互運用性を利用して、不安を感じることなくSwift Testingを導入し、XCTestと併用する方法を紹介します。開発を高速化しカバレッジを向上させる高度なテスト機能を段階的に導入するための、ベストプラクティスとパターンも学びます。

関連する章
- 0:07 - Introduction
- 1:08 - Swift Testing basics
- 2:50 - Migration strategy
- 5:48 - Test framework interoperability
- 7:43 - Interoperability modes
- 13:02 - Common migration patterns
- 15:34 - Parameterized tests
- 18:02 - Exit tests
- 20:04 - Next steps
リソース
- - HDビデオ
  - SDビデオ
関連ビデオ

WWDC26
- Swiftの新機能
WWDC24
- Swift Testingについて
- Swift Testingの詳細
こんにちは！
Jerryです Swift Testingチームのエンジニアを担当しています。今日はこれまでになく簡単に XCTestからSwift Testingへの移行方法をお伝えします。
Swift TestingはXcode 16で導入されました。モダンなテストライブラリでテストを記述するための表現力豊かで簡潔なインターフェイスです。 Swiftエコシステムにもうまく馴染んでいます。 Swiftの並行処理を念頭に置いて構築されているためテストケースを並列実行して結果を素早く提供します。
まずSwift Testingの基本的な構成要素をおさらいし XCTestの類似概念と比較します。次にXCTestプロジェクトへの Swift Testingの追加を行います。テストフレームワークの相互運用性機能を使って既存コードを再利用する方法もデモします。
XCTestを使っていない方もぜひ引き続きご覧ください！ Swift Testingの機能を使って XCTestが到達できなかった大胆に進む方法を紹介します！
Swift Testingの基本から始めましょう。
テストファイルの冒頭で Swift Testingフレームワークをインポートし内部型にアクセスするため testableインポートも追加します。次に新しい関数を作成し @Testマクロでアノテーションしてテストとして宣言します。
Swiftはraw識別子をサポートしておりバッククォートで示されます。スペースや句読点を混在させて長いテスト名を読みやすくできます。テスト本体では #expectマクロを使って果物が熱帯性気候を持つという期待値を作成します。新しいテストの作成はこれだけです！ @Testマクロと#expectマクロはほとんどのテストの核心的な構成要素です。 Swift Testingを初めて使う場合や記憶を呼び起こしたい場合は「Meet Swift Testing」が素晴らしいリソースです。追加の構成要素とテストワークフローを網羅しています。
#expectマクロは非常に柔軟で多くのXCTestアサーションを置き換えます。無条件失敗であるXCTFailの代替として Issue.recordを使います。
Swift Testingを使えば少ないコードでより強力で表現力豊かなテストを記述できます。ただしいくつかのシナリオでは引き続きXCTestを使います。 UI自動化とパフォーマンステストAPIは XCTestでのみ利用可能です Objective-C例外をスローするコードをテストする場合は Objective-Cで記述した XCTestも使う必要があります。 SwiftコードはSwiftのXCTestも含めこれらの例外を安全に処理できないためです。さあ皆さんもテストを書きたくなってきたはずです！
Swift Testingへの移行方法をデモします。
テストコードを少量ずつ移行する戦略を説明します。
次にテストフレームワークの相互運用性を紹介します既存テストコードを再利用できる強力なツールです。
移行をスムーズに進めるために従うべきいくつかの一般的なパターンも共有します。はい。移行戦略についてお話しします。
古いテストを変更すると小さな変更でもリスクが生じます。そのため既存のXCTestはほぼそのままにします。準備ができたら少数ずつテストを修正し最も頻繁に更新するものに集中します。
既存のテストターゲットには両フレームワークのテストを含められます。そのため新しいテストにはすでにSwift Testingが使えますただしXCTestクラスの中には置けません。はい！移行戦略が決まったので実際に試してみましょう。近所の鳥に果物の配達をトレーニングするアプリを作りました。鳥が季節の変わり目に渡りをするように私もSwift Testingへ移行する季節だと思います。
こちらがFruitデータ構造用の XCTestスイートです。最近フルーツに気候情報を追加しましたがまだテストしていません。 Swift Testingを使って新しいテストを追加したいのですがこのファイルを離れずにできます！まずSwift Testingフレームワークをインポートします。
次にこのファイルの末尾にテストを追加します。
Swift Testingがテストスイートの外に配置できるのが気に入っています。テストが増えたら後で親スイートを作れます。 Testナビゲータで新しいテストが追加されています。メニューを開いてを選択します。
完了しました！新しいテストが正常に実行されました。
一部のテストはより多くのセットアップが必要です。このテストはフルーツの配列のすべての名前がユニークか確認します。このテストは元々アサーションのセットアップに複数行のコードを使っていました。
後でテストを実行したとき失敗の原因を理解するのが困難でした。テストはストーリーを伝えようとしましたがコードに埋もれてしまいました。この複数ステップのアサーションをヘルパー関数に抽出しました。何をテストしているかどうテストするかが明確になりました。仕上げとしてファイルと行番号のパラメータを提供し XCTFailに渡しました。
Xcodeはヘルパーを呼び出した行に失敗を紐付けます。
Swift Testingで新しいテストを作成したいのですがこのヘルパーを呼び出して最終的にXCTFailも呼びます。しかしXCTFailはSwift Testingの一部ではありません。
ここでテストフレームワークの相互運用性が役立ちます！ 1つのテストフレームワークのAPIを安全に呼び出せる機能で別のフレームワークのテスト本体から呼び出せます。
相互運用性を考える際には 2つの方向があります。 XCTestのAPIを呼び出して Swift Testingのテストで問題を報告できます。これがassertUniqueヘルパーを再利用する際に起こることです。逆方向ではSwift Testing APIを呼び出して XCTestで問題を報告できます。これは後で説明します。
いずれの場合もクロスフレームワークの問題が発生します問題報告APIとそれが呼ばれるテストが異なるフレームワークに属しています。 Xcodeはデフォルトで相互運用性を有効にして処理します。方法をお見せします。
assertUniqueヘルパーを testUniqueFruitNamesで呼び出します。ヘルパーはXCTFailを使って失敗を報告します。同じ本体を持つSwift Testing テストを別途作成しました。このヘルパーは同じ失敗を報告するはずですがこのテストではクロスフレームワークの問題になります。
このテストを実行した後の結果を比較してみましょう。
テストがパスしましたが実際には失敗すると思っていました上のXCTestと同様に。テストの失敗は良いことですヘルパーがバグを検出しているという証拠だからです。いくつかのメッセージがありますね。クリックして確認します。
相互運用性により紫の三角で示された 2つの警告が作成されました。これらはエラーではないためテストはまだパスしています。 1つ目の警告はLycheeが重複した名前であることを示し 2つ目の警告は XCTFailをSwift Testingの Issue.recordに置き換えるよう指示します。
相互運用性にはクロスフレームワークの問題の処理に異なるモードがあります。 limitedモードを説明しました。このモードではXCTestからのクロスフレームワークの問題は警告です。 Xcode 27以前に作成したテストプランはlimitedモードを引き継ぎます。新しいプロジェクトでは Xcodeはcompleteモードを使います。このモードでは同じ問題がエラーとして残ります。
テストプランの設定でいつでもモードを変更できます。セクションにあります。 completeモードにするとテスト結果がどう変わるか確認します。テストプランを編集します。
相互運用性でフィルタして
モードをCompleteに変更します。
「Unique fruit names」テストに戻って再実行します。
テストが失敗しました。メッセージを確認します。
completeモードはXCTFailで作成されたエラーを保持します。また移行を促す警告も保持されます。 completeモードはlimitedモードより 1段階上です。クロスフレームワークの問題を警告からエラーに昇格させるため見落としにくくなります。
completeモードよりさらに上が strictモードです。 XCTestからのクロスフレームワークの問題に対して strictモードはfatalエラーでテストを即座に停止します。 XCTest APIをSwift Testing APIに置き換える箇所を見つけるのに役立ちます。モードをstrictに変更済みです。テストを再実行します。
おお！ヘルパー関数のXCTFailを呼び出した箇所でテストが停止しました！このメッセージを確認します。
再びXCTFailを置き換えるよう指示されていますしかしこのヘルパーを呼び出す XCTestがまだあることも忘れずに。そのため相互運用性はSwift Testingからのクロスフレームワーク問題もサポートします。すべてのモードでこれらの問題はエラーのままです。つまり両フレームワークのテストから Swift Testing APIを呼び出せます。 XCTFailの置き換えは数ステップで完了します。まずXCTestのインポートを Swift Testingのインポートに置き換えます。
次にXCTFailをIssue.recordに置き換え sourceLocationが元のファイルと行番号パラメータを置き換えます。
ヘルパーを更新したらすべてのテストケースを再実行します。
CMD+Uを使いますこれはProduct Testのショートカットです。
更新後のヘルパーで新しいテストと元のXCTestの両方が期待通りに失敗します。テストフレームワークの相互運用性のおかげで XCTest APIを Swift Testing APIに置き換えてもテストの意味は変わりませんでした。もう1つまだ紹介していないモードがあります。モードをnoneに設定して相互運用性をオプトアウトできます。オプトアウト後はXcodeがクロスフレームワークの問題を報告しませんどちらの方向でも。しかしこれらの問題はアプリのバグを示す可能性があります。相互運用性を無効にするとそのバグを見逃します。このモードを使う必要がある場合は一時的にのみ使用してください。代わりにcompleteまたはstrictモードを使用してください。 completeモードはクロスフレームワークの問題をエラーとして維持し limitedモードから 1段階上げるのに適しています。 strictモードはまさに厳格です！ XCTestからのクロスフレームワーク問題を完全に防ぎたい場合に最適です。相互運用性とその異なるモードは Swift Packageプロジェクトでも使えます。こちらはswift-tools-version: 6.3で作成したプロジェクトの例で XCTestからのクロスフレームワーク問題を生成するテストがあります。デフォルトではSwift 6.4ツールチェーンが limitedモードを有効にします。
swift testコマンドでこのプロジェクトを実行するとクロスフレームワーク問題が警告として報告されます。
completeモードを使うにはパッケージをswift-tools-version 6.4以降に更新します。
ツールバージョンを上げると先ほどの問題がエラーになります。
環境変数を使っていつでもデフォルトモードを上書きできます。 SWIFT_TESTING_XCTEST_INTEROP_MODE 値にはモード名を小文字で指定します。
最後に相互運用性は両テストフレームワークの限定されたAPIセットをサポートします。先ほどXCTFailと Issue.record APIをデモしました。 XCTestでは他のすべてのテストアサーションもサポートし Swift Testingでは両方の期待値マクロをサポートします。 #expectと#requireです。 Swift TestingのKnown Issue APIは XCTestアサーション失敗を既知としてマークでき Test.cancelはXCTestのテストケースをスキップできます。
移行の過程でいくつかの一般的なパターンに遭遇するかもしれません。それらへの対処のヒントを共有します。
最初のパターンはテストのスキップです。 XCTestではXCTSkip APIを使ってテストをスキップします。
Swift Testing APIで置き換えるには Test.cancelを使います。 Swift Testingで新しいテストを書く場合も Test.cancelは同様に機能します。しかしSwift Testingにはtraitがありますテスト関数やスイートに添付できるアノテーションです。
テストの有効化ロジックをテスト本体の外に移動して enabledまたはdisabledトレイトを使います。
もう1つの一般的なパターンは失敗時の停止です。 XCTestでは continueAfterFailureプロパティを falseに設定します。これにより最初のアサーション失敗でテストが停止します。 Swift Testing APIで置き換えるには #requireマクロを使います。失敗時にエラーをスローしてテストを停止します continueAfterFailureを設定する必要はなくなります。 Swift Testingではどの期待値がテストを停止しどれが停止しないかを選べます。
詳細についてはデベロッパドキュメントの「Migrating a test from XCTest」を参照してください。より多くのシナリオを網羅しており移行の過程での参考資料として最適です。 XcodeのCoding Assistantもこのドキュメントを参照しています。移行戦略の策定や作業のレビューを支援できます。移行の一部を自動化するスキルも備えています。多くのことをカバーしました！まとめとして Swift Testingへ自信を持って移行する方法をお伝えします。
準備ができるまでXCTestの修正を急ぐ必要はありません。 Swift Testingで新しいテストを書くことに集中します。相互運用性を活用することで XCTest APIをラップするヘルパーコードを再利用できます。
その過程でXCTestからのクロスフレームワーク問題が浮かび上がります。相互運用性によりXCTest APIを Swift Testing APIに置き換えてこれらの問題を解決できます Xcode 27ではデフォルトで相互運用性が有効です。今後のクロスフレームワーク問題をすべて確実に対処するために completeまたはstrictモードにアップグレードしてください。
次にSwift Testingにスポットライトを当てます。
Swift Testingに移行するとテストをさらに強化する新しいツールが使えます。パラメータ化テストから始めましょう。
これは異なる引数で繰り返されるテストです。各引数が個別のテストケースになります。パラメータ化テストケースを含むすべてのSwift Testingテストはデフォルトで並列実行されます。直列実行より高速になります。こちらの例を見てください。
プロジェクトのbirdテストを Swift Testingに移行しました。すべての鳥が40〜100回羽ばたけるか確認します。その組み合わせごとに別々のテストは書けません数が多すぎます。元のXCTestの本体ではネストされたループを使ってすべての組み合わせを生成しました。テストを実行します。
いくつか気になる点がありました。組み合わせが多いためテストの完了に時間がかかりました。また失敗しましたがどの鳥が失敗したかがわかりません。
XCTestを使い続けていればエラーをキャッチするかデバッガでテストを実行する必要があります。もっと良い方法があります。これをパラメータ化テストにしましょう。テスト本体からループを削除し
代わりにbirdとcountをテスト関数のパラメータとして定義します。
birdsとcountsの入力を @Testマクロの引数として提供します。
Swift Testingは最初の引数から各birdと 2番目の引数から各countをペアにします。テストを再実行します。
おお！今回はテストがほぼ瞬時に完了しました Swift Testingがすべての組み合わせを並列実行したためです。 Testナビゲータでパラメータ化テストの左側に開示矢印が表示されています。クリックしてテストしているすべての組み合わせを表示します。
非常に多くのテストケースがあります。失敗している組み合わせを見つけなければなりません。 Testナビゲータで失敗したテスト結果をフィルタします。
ありました！ツバメは43回未満では羽ばたけません。パラメータ化テストを使ってテスト実行が大幅に強化されました。結果が速くなっただけでなくどのテスト入力が失敗したかが明確にわかります。
次にexit testsでテストカバレッジを強化する方法をご紹介します。 exit testsはmacOS Linux FreeBSD Windowsのみサポートされます。テストカバレッジが必要なコードを探していて Birdイニシャライザに何かを見つけました。
新しいBirdに空の名前が渡された場合 preconditionの失敗でプログラムを停止します。
すでにテスト済みかどうかはメニューで確認できますを表示します。
カバレッジアノテーションが preconditionを赤で表示しておりこのコードがテストされていないことを示します。 exit testはこのカバレッジを追加するのに最適なツールです。
exit testは #expectマクロで定義します。期待するプロセスの終了条件を指定し exit testの本体を指定します。テストを開始すると Swift Testingがexit testの本体を子プロセスで実行します。そのコードは分離されているためクラッシュしても他のテストを妨げません。 exit testは子プロセスの完了を待ち終了ステータスを確認してテストの成否を判断します。テストスイートのこのextensionに新しいテストを追加できます。 #expectマクロを使って exit testを作成しプロセスが失敗で終了するよう指定します。
exit testの本体内で空の名前のBirdを作成します。クラッシュするはずですが分離されます Swift Testingがこのコードを別プロセスで実行するためです。すべてのテストを実行します。
exit testがパスしました！もう一度カバレッジを確認します。右クリックして Birdイニシャライザのを選択します。戻ったのでカバレッジを再度確認します。カバレッジアノテーションが preconditionを緑で表示しテスト済みを示しています！
テストを強化する2つの方法を簡単にご紹介しました Swift Testingの改善アイデアがあればぜひコントリビュートしてください！ Swift Testingはオープンソースだからです。 GitHubのSwiftLang organizationの一部です。これまで以上に多くのプラットフォームで利用可能で今年からFreeBSDのフルサポートも開始されました。
Testing Workgroupがプロジェクトを管理しており Swiftコミュニティのメンバーなら誰でも参加できる定例会議を開催しています。新機能はSwift Evolutionによって導かれます。実は相互運用性もその1つです！ Swift Forumsに参加して意見やアイデアを共有してください。さあ鳥のように羽ばたいて Swift Testingに移行しましょう！ Xcode 27の相互運用性によりこの移行がこれまでになく容易になりました。プロジェクトで試して異なるモードを探ってみてください。その過程で強力なツールを活用できますパラメータ化テストや exit testsなどです。さらに詳しくはWWDC 2024の「Go further with Swift Testing」をご確認ください。テストのリノベーションを楽しんでください！

1:12 - Name a test using a raw identifier

import Testing

@testable import DemoApp

@Test func `Default climate: tropical`() async throws {
    let fruit = Fruit(name: "Coconut")
    #expect(fruit.climate == .tropical)
}

5:03 - Wrap XCTFail in a test helper function

func testUniqueFruitNames() async throws {
    assertUnique(Market.fruits + [Fruit.lychee])
}

// TestHelpers.swift

func assertUnique(_ fruits: [Fruit], file: StaticString = #filePath, line: UInt = #line) {
    var uniqueNames = Set<String>()
    for name in fruits.map(\.name) {
        if !uniqueNames.insert(name).inserted {
            XCTFail("Duplicate name: \(name)", file: file, line: line)
        }
    }
}

10:12 - Replace XCTFail with Issue.record in the test helper

import Testing

func assertUnique(_ fruits: [Fruit], sourceLocation: SourceLocation = ...) {
    var uniqueNames = Set<String>()
    for name in fruits.map(\.name) {
        if !uniqueNames.insert(name).inserted {
            Issue.record("Duplicate name: \(name)", sourceLocation: sourceLocation)
        }
    }
}

12:15 - Run Swift Package tests with the strict interoperability mode from Terminal
```
> SWIFT_TESTING_XCTEST_INTEROP_MODE=strict swift test
```

13:10 - Common migration: skipping tests

let isFall = false

// XCTest
func testSwallowFallMigration() async throws {
    try XCTSkipIf(!isFall, "Wrong season for migration")
    // ...
}

// Test.cancel interoperability from Swift Testing
func testSwallowFallMigration() async throws {
    if !isFall {
        try Test.cancel("Wrong season for migration")
    }
    // ...
}

// ✅ Prefer test trait in Swift Testing
@Test(.enabled(if: isFall, "Wrong season for migration"))
func `Swallow fall migration`() async throws {
   // ...
}

13:41 - Common migration: halting after test failures

func testExample() async throws {
    #expect(Fruit.banana.climate == .temperate)

    try #require(Fruit.banana == Fruit.plantain)
    XCTFail("This is never reached")
}

15:57 - Example of nested loops which can be converted into a parameterized @Test function

struct BirdTests {

    @Test func `Birds flap wings successfully`() async throws {
        for bird in Aviary.birds {
            for count in (40...100) {
                try await bird.flapWings(count: count)
            }
        }
    }

}

16:47 - Refactor nested loops into a parameterized @Test function

struct BirdTests {

    @Test(arguments: Aviary.birds, 40...100)
    func `Birds flap wings successfully`(bird: Bird, count: Int) async throws {
        try await bird.flapWings(count: count)
    }

}

18:21 - Precondition check on empty input name in an initializer

// In `Bird.init(...)`
if name.isEmpty {
    preconditionFailure("Bird name cannot be empty")
}

19:27 - Add coverage for precondition failure with exit test

extension BirdTests {

    @Test func `Bird with empty name crashes`() async throws {
        await #expect(processExitsWith: .failure) {
            _ = Bird(name: "")
        }
    }

}

- 0:07 - Introduction
- How to fearlessly migrate from XCTest to Swift Testing using the new interoperability feature.
- 1:08 - Swift Testing basics
- A quick review of core Swift Testing building blocks — the @Test macro, #expect, and how they compare to XCTest assertions.
- 2:50 - Migration strategy
- Covers the recommended incremental approach: leave existing XCTests in place, and start writing new tests in Swift Testing right away.
- 5:48 - Test framework interoperability
- Introduces the interoperability feature that lets you safely call XCTest or Swift Testing API from within a test belonging to the other framework.
- 7:43 - Interoperability modes
- Walks through the four interoperability modes — Limited, Complete, Strict, and None — and how to configure them in Xcode Test Plans and Swift packages.
- 13:02 - Common migration patterns
- Covers practical patterns you will encounter during migration, including replacing XCTSkip with Test.cancel or traits, and continueAfterFailure with #require.
- 15:34 - Parameterized tests
- Shows how to replace loop-based XCTest cases with Swift Testing parameterized tests for faster parallel execution and clearer failure reporting.
- 18:02 - Exit tests
- Demonstrates how to use Swift Testing exit tests to cover code paths that call preconditionFailure or crash, running them safely in a child process.
- 20:04 - Next steps
- Recaps the migration path, highlights Swift Testing open-source availability and cross-platform support, and encourages community participation.

「今すぐ始める」を詳しく見る

最新情報

プラットフォームを詳しく見る

特集

テクノロジーを詳しく見る

特集

コミュニティを詳しく見る

特集

ドキュメントを詳しく見る

リリースノート

ダウンロードを詳しく見る

特集

サポートを詳しく見る

特集

クイックリンク

関連する章

リソース

関連ビデオ

WWDC26

WWDC24