Xcode 27 Swift TestingとXCTestの相互運用はどう選ぶ？2026年ガイド

Swift TestingとXCTestは、同じテストターゲット内で共存できます。相互運用モードが調整するのは、片方のフレームワークからもう片方のAPIを使った際に生じる問題の扱いです。テスト全体をどちらか一方へ切り替える設定ではありません。適用範囲はAppleのテスト概覧とXCTestの説明で確認できます。

同じテストパッケージに両方を含められますか。
含められます。たとえば、Swift Testingのテスト関数内でXCTestのアサーションを呼び出す構成が、相互運用を確認する最小例になります。

import Testing
import XCTest

@Test func valueMatchesExpected() {
    XCTAssertEqual(2 + 2, 4)
}

このコードを単に実行できるかだけでなく、フレームワーク間の呼び出しがどのように記録されるかを見ます。Swift Testing側で問題を記録するAPIや深刻度の扱いは、Issue.recordの仕様も確認してください。

選択肢はlimited、complete、strict、noneです。違いは「テストが動くか」だけでなく、クロスフレームワークの呼び出しをどれほど可視化し、どの深刻度で扱うかにあります。モードの意味はXcode 27のリリースノートと移行ドキュメントで照合してください。

• limited：互換性に配慮した扱いを維持したい場合の選択肢です。既存の挙動を急に厳格化せず、移行時の警告や診断を確認したいときに使います。
• complete：クロスフレームワークの問題を、元の深刻度に沿って扱います。新旧テストを併用しながら、問題を過小評価せず段階移行する起点に向いています。
• strict：指定されたクロスフレームワーク呼び出しを厳しく制御したい場合に選びます。呼び出しを許容しない方針が明確なチーム向けです。
• none：相互運用に関する扱いを無効にする選択です。診断を切り分ける一時的な比較には使えますが、CIを通す目的だけで常用すると問題を見えにくくします。

limitedとcompleteのどちらから試すべきですか。
移行の評価はcompleteから始め、既存テストで記録される問題と深刻度を確認してください。互換性を保ったまま移行状況を観察する必要がある場合はlimitedと比較し、チームが許容する結果をTest Planに明記します。

Xcode 27を使っているという理由だけで、すべてのテスト計画が同じモードだとは限りません。新規プロジェクトと、以前のXcodeで作成したTest Planでは設定が異なる可能性があります。古い計画がlimitedを引き継いでいる場合もあるため、IDEのバージョンから設定を推測しないでください。

アップグレード後もlimitedのままになるのはなぜですか。
既存Test Planに保存された設定が、新しいXcodeの新規プロジェクト向け設定と異なるためです。Test Planの編集画面で現在の相互運用設定を確認し、Appleのテスト計画の構成説明とリリースノートを照合します。

設定を見つけたら、値だけでなく、そのTest Planがどのターゲットや実行先に適用されるかも記録します。複数の計画を使うプロジェクトでは、一つの画面を確認しただけで全体を判断しないでください。

Swift PackageとXcodeプロジェクトでは、設定を確認する入口や既定の扱いが同じとは限りません。Swift Packageではswift-tools-versionを含むパッケージ側の条件も確認対象になります。Swift 6.4を含め、ツールチェーンのバージョンだけから全プロジェクトの既定値を推定しないでください。

両方の既定モードは同じですか。
一律には判断できません。Appleの移行資料と現在のパッケージ設定を確認し、同じテストケースをコマンドラインとXcodeの両方から実行してください。環境変数などを使う構成なら、その設定が各実行経路に渡っているかも照合し、別プロジェクトの値をそのまま流用しないようにします。

コマンドラインからの実行方法や結果の読み方は、Appleのテスト実行ガイドを参照できます。ローカルで通るのにCIで結果が異なる場合は、まずテストコードを書き換えず、選択されたTest Plan、パッケージ設定、実際の起動経路を分けて記録してください。

移行を完了扱いにする前に、テストが成功したかだけでなく、クロスフレームワークの問題が記録されているか、深刻度がチームの想定と合っているかを確認します。旧XCTestテストが継続して動くことも、別に検証してください。

次の項目をすべて確認できたら、チーム標準のモードを決めます。

• [ ] Swift TestingのテストからXCTestアサーションを呼ぶ最小サンプルを用意した。
• [ ] 選択した相互運用モードとTest Plan名を記録した。
• [ ] 問題がテスト結果に現れるか、また深刻度が想定どおりかを確認した。
• [ ] 既存のXCTestテストと新しいSwift Testingテストを同じ実行条件で動かした。
• [ ] Xcode、コマンドライン、CIの結果を並べ、差があれば設定と実行入口を特定した。
• [ ] noneを使った場合は、調査目的と通常設定へ戻す条件を記録した。

CIを緑にするためだけにnoneを選ぶと、移行で把握すべき問題まで見落とすおそれがあります。設定変更前後のテスト結果を保存し、問題の記録と深刻度がどう変化したかを根拠に判断してください。

遠隔Mac上でテストを実行する場合も、ローカルと同じ設定だと決めつけず、Test Plan、Swiftツールチェーン、起動経路を照合します。実プロジェクトの混合テストを使い、ローカルのXcode実行、コマンドライン実行、遠隔CIの結果を比較してください。ここで確認すべきなのは設定と結果の一致であり、特定のホスト構成や性能を推測することではありません。

Xcodeを実行できるMacが手元になく、移行用のテスト環境を一時的に用意したい場合は、購入前にCALMVPSの料金と利用期間を確認できます。Linux環境ではXcodeのテストをそのまま実行できず、手元のMacだけに依存するとCIとの実行条件を分離しにくくなります。一方、長期にわたり安定した負荷をかける場合や、物理デバイス・インターフェースが必須の場合は、自前のMacが適することもあります。まず既存Test Planのモードを確認し、同じテストサンプルでローカルとCIの結果を比較してください。Mac環境が不足する短期の移行検証には、CALMVPSのMac利用方法を選択肢として確認できます。