Swift Testing vs XCTest：2026年、独立開発者は全量移行すべきか？

大量のXCTestを抱え、一括書き換えによって回帰テストの基準を壊したくない既存アプリの開発者が対象です。

新しいテスト体系を作り、パラメータ化テストやSwiftの並行処理に適した記述を取り入れたい独立開発者にも役立ちます。さらに、リモートMac、Swift Package Manager、継続的インテグレーションでツールチェーンを揃えたい場合にも確認すべき論点があります。

移行計画をファイル単位で始めると、書き換え作業そのものが目的になりがちです。先にテストが何を検証しているかを分類し、「移行」「保留」「併用」のいずれかを決めます。

AppleはSwift TestingとXCTestの移行および併用について公式資料を公開していますが、XCTestを直ちに廃止するという意味ではありません。XCTestからの移行に関するAppleの説明でも、テストの種類に応じた移行が前提です。

新しいiOS・macOSプロジェクトでは、通常の単体テストをSwift Testingで始めると、テストの意図をコード上で分けやすくなります。@Testはテスト宣言、#expectは条件確認、#requireは後続処理に必要な前提確認、traitsは実行条件や分類、パラメータ化テストは入力値の組み合わせをまとめて扱うために使います。

最小構成のイメージは次のようになります。

import Testing

struct PriceCalculatorTests {
    @Test(arguments: [1, 2, 3])
    func calculatesTotal(quantity: Int) {
        let total = PriceCalculator(unitPrice: 100).total(quantity: quantity)
        #expect(total == quantity * 100)
    }
}

ここで重要なのは、Swift Testingの記法へ変えることではなく、テストが直接業務ロジックを検証していることです。画面遷移や実機操作が必要なら、別のXCTest UI Tests Targetを残してください。Xcodeのテスト追加手順に沿って、ロジック用とUI用の実行単位を分けると、失敗原因を追いやすくなります。

Swift Testingの公式リポジトリはSwift 5.9以降を対象として示しています。Swift Testing公式リポジトリにある対応条件を確認し、利用中のSwift PackageやCIイメージが条件を満たすか先に確認します。Xcode 27 Betaの挙動を正式版の保証として扱わず、採用判断は使用するXcodeの版と実行入口ごとに記録してください。

既存のXCTestを移行する場合、次の順番で候補を絞ると、テスト全体を止めずに進められます。

1. 現在修正中で、業務ロジックを直接呼び出すテストを選びます。
2. 複数のテストから使われるHelper、Fixture、Factoryの依存関係を洗い出します。
3. Helperの挙動を変えずに、1つの小さなテスト群だけSwift Testingへ移します。
4. 移行前後で、同じ欠陥を投入したときに同じテストが失敗するか確認します。
5. 成功、失敗、スキップ、前提条件エラーの結果をTest Plan単位で比較します。
6. 変更頻度が低く安定しているテストは、無理に書き換えずXCTestのまま維持します。

同じテストBundle内で両フレームワークを扱える場合でも、HelperがXCTestの型やライフサイクルに依存していると、そのまま共有できないことがあります。したがって「同じターゲットで動く」という確認だけでは不十分で、テストの意味、失敗位置、スキップ条件が移行前と一致しているかを受け入れ条件にします。

Xcodeではテストの整理方法がフィードバックの受け取り方に影響します。テスト整理に関する公式ガイドを参照し、ロジック、UI、性能の結果を同じ一覧に埋もれさせない構成にしてください。

Swift Testingを新しい標準として扱うことと、XCTestを削除することは別の判断です。UI自動化は画面要素の検索、タップ、入力、アプリとシステムの境界を検証します。性能テストは処理時間やメモリなどを測定するため、単なる真偽値の確認とは目的が異なります。

また、Objective-Cとの相互運用や例外処理を含むテストでは、移行によって失敗の意味が変わる可能性があります。該当部分はXCTestに残し、Swift Testingは計算、状態変化、通信層の変換結果など、直接呼び出せる範囲に限定する方が回帰基盤を守れます。

条件分岐で決める移行範囲

• 業務ロジックを直接呼び出し、現在も変更が多いなら、Swift Testingへ移行します。
• 画面を操作して結果を確認するなら、XCTest UI Testsを維持します。
• 性能の基準値を比較するなら、計測結果が同じ意味になるまでXCTestを残します。
• Objective-C例外や古いHelperに依存するなら、先に依存関係を分離し、すぐには移行しません。
• 失敗の帰属や結果ファイルをCIで再現できないなら、移行範囲を戻して併用にします。

WWDC26ではテストフレームワークの相互運用と段階的な移行が扱われています。WWDC26のテスト移行セッションを確認し、Beta固有の動作と、長期的に採用できる設計上の考え方を分けて記録してください。

Swift TestingだけでXCTestを完全に置き換えられますか？

現段階では、すべてのXCTestを一括置換する判断は適切ではありません。単体テストや業務ロジックの統合テストは移行しやすい一方、UI自動化、性能計測、特定のObjective-C例外テストではXCTestを残す必要があります。

既存のXCTestはどこから移行すべきですか？

最初の候補は、現在も頻繁に修正され、業務ロジックを直接呼び出しているテストです。共有Helperを確認した後、長期間変更されていない安定テストは後回しにします。ファイル数ではなく、変更頻度と回帰リスクで順番を決めます。

2つのフレームワークを同じTargetで実行できますか？

公式の移行方針は段階的な併用を想定しています。ただし、Scheme、Test Plan、Xcodeのテスト実行、Swift Package Managerのswift testでは結果の見え方が同じとは限りません。対象の入口ごとに検出数と結果形式を確認します。

UIテストや性能テストを残すのは技術的な後退ですか？

後退ではありません。UIテストは画面とシステム操作を、性能テストは測定対象を検証するため、単体テスト用の仕組みへ統一すると目的を失うことがあります。テスト能力に応じてXCTestを残すことが、保守上の合理的な選択です。

リモートCIで移行結果をどう受け入れますか？

Xcode、Swift、Scheme、Test Plan、実行コマンドを固定したうえで、発見数、失敗の帰属、スキップ条件、結果ファイルを比較します。接続断やホスト再起動後にも単体テストとUIテストを再実行し、結果を回収できることまで確認します。テスト結果の実行・解釈に関する公式説明が確認基準になります。

Swift Package Managerのswift testで実行できるロジックテストと、XcodeのScheme・Test Planを通して実行するAppleプラットフォーム統合テストは、同じ結果になるとは限りません。WindowsやLinuxで先に検証できるSwiftコードがあっても、Xcode、Simulator、署名、画面操作を含む確認にはmacOSが必要です。

CIでは、いきなり厳格な互換性チェックへ切り替えないことが重要です。まず両フレームワークを並行実行し、共有Helperの問題とテスト発見漏れを解消してから、より厳しい互換性検証へ進めます。失敗したジョブがどのフレームワークのどの入口で発生したか分からない状態では、移行を進めるべきではありません。

リモートMacを使う場合は、次の項目を1つずつ確認します。

• XcodeとSwiftの版を固定し、更新時には再検証します。
• SchemeとTest Planをリポジトリで管理します。
• Swift Testing、XCTest単体テスト、XCTest UI Testsを別々に識別できるようにします。
• .xcresultなどの結果ファイルをジョブ終了前に保存します。
• 接続断、ログアウト、ホスト再起動の後でも同じ入口から再実行できるか確認します。

ローカルMacを常時CI用に確保できない場合は、NUKCLOUDのリモートMacサービス概要を確認し、必要なXcode版、Test Plan、結果ファイルの保存要件を先に整理してください。利用地域や接続条件を比較する場合は、日本向けのMac利用案内も判断材料になります。

移行作業の完了条件は、Swift Testingのファイル数を増やすことではありません。プロジェクト内のテストを「移行する」「XCTestに保留する」「互換性を確認してから決める」の3分類に分け、それぞれの理由と受け入れ証拠を残せることが条件です。

現行の環境でTest Planが正しくテストを発見し、失敗が適切なテストへ帰属し、結果ファイルが保存され、再接続や再起動後にも同じテストを繰り返せるなら、段階的な移行を続けられます。反対に、Xcode 27のBeta挙動や実行入口の差で診断性が落ちる場合は、XCTestを残した併用構成へ戻してください。

最後に、ローカル環境だけでこの検証を続ける場合、MacをCI専用に常時稼働させる費用、Xcode更新時の再確認、ディスク容量、接続断後の復旧作業が継続的な負担になります。自前のMacは長期の安定した高負荷処理や物理デバイス接続には向きますが、短期の移行検証では遊休時間が発生しやすく、一般的なクラウド環境ではXcodeを動かせるmacOS実機やUIテストの条件を満たせない場合があります。

そのため、双方向のテスト実行やTest Planの検証を一時的に行う用途では、NUKCLOUDのリモートMacを使う方が環境を固定しやすく、ローカルMacを買い足すより判断を小さく始められます。まずはプロジェクトを「移行」「保留」「待機」に分け、必要なテスト入口と結果保存条件が決まった段階で、NUKCLOUDの利用案内から適した環境を確認してください。

最終更新日：2026年9月2日。Xcode 27のBeta状態、Swift TestingとXCTestの移行方針、テスト実行入口について、Apple Developer公式資料およびSwift Testing公式リポジトリを基に確認しています。