[ SECTION_01 ] まず結論：新規の単体テストからSwift Testingを試す
Appleの移行ガイドは、Swift TestingとXCTestを併用する方法を案内しています。したがって、XCTestを一括削除する必要はありません。新しい単体テストはSwift Testingを優先し、既存テストは失敗の伝わり方や実行環境を確かめながら移行します。UI自動化など、XCTestの機能が必要なテストは残します。
この記事の対象 - XCTestの単体テストが増え、移行範囲を見極めたい独立開発者。 - 新旧のテストが混在しており、アサーションや補助関数の挙動を心配する小規模チーム。 - ローカルまたはリモートMacでテストを繰り返し実行し、CIの結果を安定させたい担当者。
[ SECTION_02 ] 移行判断はテストの責務と依存機能で分ける
移行の単位はファイルやターゲットではなく、テストが検証する責務です。純粋なSwiftのロジックを検証し、XCTest固有の機能に依存しない単体テストは、最初の候補になります。
対して、画面操作や性能計測など特定のXCTest機能を使うテストは、同じ基準で移せるとは限りません。Swift Testingの概要とXCTestの機能説明を読み、現在のテストが使うAPIを確認します。
| 選択肢 | 向いている条件 | 主な確認点 | 判断 |
|---|---|---|---|
| 新規の単体テストからSwift Testingを採用 | 純粋なSwiftコードを検証し、移行対象が新規分に限られる | テスト検出、アサーション失敗、CIでの結果取得 | まず試す |
| 既存の単体テストを段階移行 | XCTestsの責務を個別に切り出せ、同じ入力で結果を比較できる | 補助関数、共有状態、失敗報告の差 | 小さなグループから進める |
| XCTestを継続 | UI操作、性能計測、その他のXCTest固有機能に依存する | 代替機能の有無と移行後の検証方法 | 必要なテストに残す |
| 新旧を併用して保留 | 実行環境や互換性の確認が終わっていない | どちらのテストも実行され、失敗が集約されるか | 証拠がそろうまで維持 |
評価点で移行の優先順位をつける
下記はフレームワークの性能評価ではなく、移行作業の優先順位をそろえるための目安です。テストの責務、互換性、並行実行、特殊機能、CI再現性の各項目を、未確認なら0、条件付きで確認できたら1、繰り返し確認できたら2として採点します。
- 0〜3点： 既存テストを保ち、互換性やCIの確認から始めます。
- 4〜7点： 新規テストに採用し、独立した単体テスト群を少しずつ移します。
- 8〜10点： 対象を広げられる状態です。ただし、UIや性能テストなどの例外は別に判定します。
点数は移行可否の自動判定ではありません。たとえば、合計点が高くてもアサーション失敗がテスト結果に伝わらないなら、そのテスト群は移行を止めます。
注意：Swift Testingへ書き換えただけでは、テストが正しく実行されたことの証明になりません。検出件数、意図的に発生させた失敗、CI上の終了結果まで確認します。
[ SECTION_03 ] 互換性は「同じプロジェクトで動くか」だけで判断しない
Swift TestingとXCTestを同じプロジェクトで使う際は、テストの検出と報告に加え、失敗の意味が維持されるかを確認します。特に、XCTestのアサーションを呼び出す補助関数や、独自のテストヘルパーを使う箇所は、成功例だけでなく失敗例を実行します。
Appleの移行に関する互換性と併用の説明を基準にし、対象のXcodeで実際に試します。互換性に関する問題報告をオフにすることを、問題解決の標準手順にしてはいけません。警告を消す前に、失敗がランナーとCIへ伝わることを再現します。
失敗の伝達を確かめる手順
- 移行候補から、小さく独立したテスト群を選びます。呼び出し先や補助関数の依存関係も記録します。
- 同一の入力と前提条件で、移行前後の期待結果を決めます。正常系だけでなく、失敗すべきケースも用意します。
- XCTestのアサーションや補助関数を経由するテストでは、条件を意図的に外して実行します。
- テストランナーの結果とCIの終了状態を照合します。失敗が成功扱いになったり、結果から消えたりした場合は移行を止めます。
- エラー報告を変更する場合は、影響するテスト群を絞って再検証します。警告を無効化した状態だけで完了と判断しません。
Swift Package Managerは依存と実行経路をそろえる
Swift Package Managerを使う場合、テストターゲットの依存関係と、手元で実行しているツールチェーンを一緒に確認します。小さなテストターゲットで両フレームワークが検出され、パッケージのテスト実行とCIの双方で結果を取得できることを確かめてから、対象を増やします。
Xcode 27を使う計画がある場合も、利用可否を名称だけで判断せず、使用中のビルド環境に該当するリリースノートで変更点を確認します。Swift TestingのAPIや互換動作は、プロジェクトが実際に使う環境で検証してください。
[ SECTION_04 ] 並行実行と隔離は速度ではなく再現性で評価する
並行実行を有効にする前に、テスト間で状態を共有していないかを調べます。共有ファイル、固定名の一時データ、同じネットワークリソース、実行順への依存があれば、並行実行時に競合や不定な失敗を起こす可能性があります。
Appleの並行テストに関する説明を参照しつつ、対象テストを繰り返し実行して、失敗の有無とログを保存します。結果が安定していない状態で「速くなるはず」と判断するのではなく、再現性を確認してから並行実行の範囲を広げます。
- テストごとに固有のファイルやデータを使い、後片付けが実行されるか確認します。
- 順番を入れ替えたり、単独で実行したりして、他のテストに依存していないかを見ます。
- 並行実行の前後で、同じテスト群の成否と失敗内容を記録します。
- 失敗時に対象テストと入力条件を特定できない場合は、並行実行をいったん限定します。
[ SECTION_05 ] UI自動化や特殊な失敗検証は移行境界を設ける
UIを操作するテストは、単体テストと必要な機能が異なります。画面の起動や操作を検証している場合は、XCUIAutomationの説明に照らし、現在のシナリオに必要な機能が移行先で満たされるか確認します。代替が確認できない間は、XCTestのUIテストを残します。
性能計測も別扱いです。XCTestの性能テスト機能に依存しているなら、測定対象と結果の扱いが維持されることを確かめずに置き換えません。一方、入力値の組み合わせを扱うテストではパラメータ化テストが現在の不足を解消するか、実際のケースで評価できます。プロセス終了を検証するテストも、終了テストの機能が必要なシナリオに合うかを個別に確かめます。
補足：APIが存在することと、プロジェクトのテスト目的を満たすことは別です。特殊な失敗条件は、成功時の実行だけでなく期待するエラーが記録されることも確認します。
分類してから移行するチェック手順
- 責務を分類： 純粋な単体テスト、UI自動化、性能計測、特殊な失敗検証に分けます。
- 依存を記録： XCTestのクラス、アサーション、ヘルパー、外部リソースの利用箇所を拾います。
- 候補を選定： XCTest固有の機能に依存しない単体テストから選びます。
- 互換性を検証： 新旧テストを併用し、正常系と失敗系の結果を比較します。
- 並行実行を確認： 共有状態と順序依存を点検し、繰り返し実行して失敗記録を残します。
- CIで再現： ローカルとCIで、テスト検出、結果取得、失敗の伝達がそろうか確認します。
- 対象を拡大： 記録をレビューし、問題のあるテスト群はXCTestに残して、確認済みの範囲だけ移行します。
[ SECTION_06 ] CIとMac環境では同じテスト経路を再現する
ローカルで一度通っただけでは、移行完了とは言えません。ビルド設定、テスト計画、パッケージ依存、テスト結果の保存方法がCIと一致しているかを確かめます。失敗時にテスト名や出力を追えることも、移行の受け入れ条件に含めます。
遠隔Macを含む環境で確認する場合は、チームが使うXcodeのツールチェーンとテスト実行方法をそろえます。さらに、結果ファイルを取得できるか、同じ入力で失敗を再現できるかを検証します。ホスト環境でテストが通ったという事実だけから、Swift Testing自体の性能や安定性を結論づけてはいけません。
テストに必要な環境を一時的に用意する方法と、自前のMacを継続して運用する方法は、利用期間や保守責任で比較します。購入して常設する選択肢を検討する場合は、Mac miniの購入情報も判断材料になります。リモートMacを使うなら、実際のXcode、テスト計画、結果取得手順がチームのCIに合うかを先に確かめます。
段階移行を完了とみなす条件
- 新旧フレームワークのテストが、意図した実行経路から検出されます。
- 意図的な失敗がローカルとCIの両方で失敗として記録されます。
- 並行実行の有無にかかわらず、共有状態に起因する不安定な結果が残りません。
- UI自動化や性能テストなど、移行しない対象とその理由が明確です。
- 失敗時に対象テストと結果を取得でき、再現の手順がチームで共有されています。
[ SECTION_07 ] よくある質問
Swift TestingとXCTestは同じプロジェクトで併用できますか？
併用できます。Appleの移行資料に沿って新しいテストを追加し、既存XCTestを残した状態で、両方が対象のテストランナーとCIから検出されることを確認します。フレームワークが共存することだけでなく、失敗が正しく集約されることも受け入れ条件にします。
移行せずに残すXCTestはどう見分けますか？
UI操作にXCUIAutomationを使うテスト、XCTestの性能計測を使うテスト、既存のObjective-C例外検証などは、必要な機能が保たれることを確認するまで残します。テスト名ではなく、依存しているAPIと検証したい挙動を調べて判断します。
補助アサーションが失敗を伝えるか確かめるには？
テスト条件を意図的に満たさない入力を用意し、補助関数を経由して実行します。テストランナーとCIの双方で失敗として記録され、対象を特定できることを確認します。互換性に関する警告を消すだけでは、失敗伝達の検証になりません。
Swift Package Managerでは何から始めますか？
使用するツールチェーンでSwift Testingを利用できることを確認し、小規模な単体テストを対象にします。既存ターゲットとの依存関係を保ちながら、パッケージのテスト実行とCIの両方で検出、実行、結果取得を確認してから範囲を広げます。
一括置換は、互換性の見落としやCIでの失敗検出漏れを招きます。一方、XCTestだけに固定すると、新しいテストに必要な機能を試す機会を逃すことがあります。新規の単体テストからSwift Testingを採用し、UI自動化などはXCTestに残す形なら、移行リスクをテスト単位で管理できます。
テスト環境を手元で維持する場合は、Macの調達、Xcode環境の管理、CIとの設定差分が負担になり得ます。短期間の検証や継続的なビルド環境が必要で、物理機器を自社で保守したくない場合は、NOVAKVMのリモートMacも選択肢です。利用前にチームのテスト経路を再現できるか確認し、NOVAKVMのMac環境で検証条件を相談してください。
よくある質問
Swift TestingとXCTestは同じプロジェクトで併用できますか？
併用できます。Appleの移行資料では、既存のXCTestを残しながらSwift Testingを導入する方法が説明されています。ただし、両方のテストが同じテスト実行内で期待どおり検出されるか、失敗がCIの結果に反映されるかは、対象のXcodeと実際のテスト計画で確かめてください。
どのようなXCTestをSwift Testingへ移さずに残すべきですか？
XCUIAutomationを使うUIテストや、XCTestの性能テスト機能に依存するテストは、対応する機能と移行目的を確認するまで残す判断が妥当です。Objective-Cの例外を検証する処理など、既存の仕組みを必要とするケースもあります。移行対象は単体テストから個別に選びます。
移行後もXCTestの補助アサーションは失敗を正しく伝えますか？
補助関数が失敗をどのように伝達するかを、実際に失敗するケースで確認します。意図的に条件を満たさない入力を与え、テストランナーが失敗として報告するかをローカルとCIの両方で照合してください。互換性に関する警告を無効にするだけでは、失敗が伝播する証拠になりません。
Swift Package Managerのプロジェクトではどう段階的に導入できますか？
まず対象のSwiftツールチェーンでSwift Testingを利用できることを確認し、依存状態を固定したうえで、小さな単体テスト群から追加します。既存のXCTestターゲットをすぐに作り替えず、パッケージのテストコマンドで両方が実行・報告されることを確認してから対象を広げます。