Swift 6.4の公式リリース説明では、Swift TestingとXCTestの相互運用が案内されています。まず、どちらのテストから別のフレームワークの断言を呼び出しているかを特定し、次にツールチェーン、Packageのswift-tools-version、相互運用モードを確認してください。テスト結果が予想と違っても、すぐに旧テストを書き直す必要はありません。
この記事は、旧XCTestの授業プロジェクトと新しいSwift Testingのテストを一緒に動かす学生向けです。
SwiftのツールチェーンやPackageを更新した後、結果が変わった初学者も、原因を順に切り分けられます。
Xcodeで提出用プロジェクトを確認していて、テスト結果が予想と合わない場合にも役立ちます。
最終更新：2026年10月10日。内容はSwift.orgのリリース説明と、Appleの移行ガイド、関連する公式文書を照合しています。
症状ごとに原因を分ける
「テストは通ったのに断言が効いていないように見える」「警告は出るが実行は続く」「テストが失敗する」では、確認する場所が異なります。結果の色だけで判断せず、どのテストが実行され、どの呼び出しが問題になったかを先に分けてください。
- 成功表示だが断言の失敗が見えない：Swift Testingのテストから、XCTestの断言を包んだ授業用ヘルパー関数を呼んでいないか確認します。
- 警告や診断があるが実行できる：メッセージの内容、対象テスト、呼び出し位置を記録し、相互運用モードと照合します。
- テスト失敗、または結果が出ない：フレームワーク間の断言だけでなく、テストターゲットが実行されたか、ビルドが完了したか、テストがスキップされていないかも確認します。
Swift 6.4が示すのは、2つのフレームワークを段階的に併用できることです。すべてのAPIやテストの実行・報告方法が同一になるという意味ではありません。Appleの移行ガイドを使い、問題の呼び出しがどのように扱われるかを確かめます。
呼び出し元とPackageの設定を確認する
まず、異常が起きる最小のテストを見つけます。テスト本体がSwift TestingなのかXCTestなのか、その中で使っている断言がどちらのフレームワークに属するのかを確認してください。共通のヘルパー関数を使っている場合は、関数の中までたどります。
swift-tools-versionは、PackageがどのバージョンのSwift Package Managerの機能やルールを前提にするかを示す宣言です。授業で使う教材の版にたとえると、ツールチェーンは実際にコードをビルド・実行する道具一式にあたります。PackageDescriptionの公式説明で、Packageの宣言を確認してください。
次の順で情報を記録すると、警告だけを見て設定を変える失敗を避けやすくなります。
- 使用中のSwiftツールチェーンと、実行に使ったXcodeを記録します。
- 問題が出たテストターゲットと、実際に選んだ実行先を記録します。
Package.swift冒頭などでswift-tools-versionを確認します。- 断言を呼び出すテストと、その呼び出しを包むヘルパー関数を特定します。
- テスト結果の警告・失敗内容を、呼び出し位置と合わせて保存します。
- 成功するはずのテストと失敗するはずのテストを実行し、どちらの結果が変わるか確かめます。
Xcodeのテスト実行と結果の読み方を参考に、テストが選択されていない状態と断言の異常を混同しないようにします。ビルドに失敗した場合は、相互運用モードを変える前にビルドエラーを解消してください。
診断内容に合わせてモードを選ぶ
相互運用モードは、フレームワークをまたぐ問題をどの範囲で扱い、どのように診断するかに関わります。none、limited、complete、strictというモード名だけを見て「エラーが消える方」を選ぶのではなく、対象となる問題と報告内容を確認してください。Appleの移行ガイドでは、ツールチェーンやswift-tools-versionとの関係も説明されています。
none：相互運用に関する診断を行わない設定が適切なのか、公式説明で確認します。断言の問題があるのに診断が見えない場合、解決したと判断しないでください。limited：限られた範囲の相互運用を扱う場合に、対象となる診断を公式説明と照合します。complete：より広い範囲の相互運用上の問題を確認したい場合に、診断の対象と報告内容を確認します。strict：厳格な診断が必要な場合に検討します。赤い結果を消す目的で、より緩い設定へ移すのは避けてください。
設定を指定する必要がある場合は、Appleの説明にある環境変数名と値をそのまま確認します。Xcodeの画面に設定項目があると決めつけず、実際の実行環境と公式文書を基準にしてください。相互運用の設計背景は、公式の相互運用提案ST-0021でも確認できます。
警告の文面だけを根拠に旧断言を一括置換すると、授業用ヘルパー関数の意図まで変わることがあります。まず問題を再現する呼び出しを特定し、変更は一か所ずつ行ってください。
実行の有無と断言の異常を見分ける
テスト結果が見つからないときは、相互運用の問題だと決めつけないでください。テストターゲット自体が選択されていない、テストがスキップされた、プロジェクトのビルドが失敗したといったケースでは、断言の報告を調べても原因にたどり着きません。
次の順に切り分けます。
- テストターゲットが実行対象に含まれているか確認します。
- 結果にスキップの記録やビルドエラーがないか確認します。
- テストが実行されている場合は、問題の断言とフレームワークの組み合わせを調べます。
- UIテストの場合は、単体テストと実行先やテスト手順が異なる可能性を考慮し、まず対象テストが動いたかを確認します。
XCTest内から#expectを呼ぶケースも、単に「同じファイルに書いたから失敗した」とは判断できません。テストがどのフレームワークで実行され、診断がどう報告されたかを調べてから、モードやコード変更の必要性を判断します。
よくある疑問を確認する
Swift TestingとXCTestは同じテストファイルで使えますか？
Swift 6.4では両フレームワークの相互運用が案内されています。ただし、同じファイルに書けば常に同じ実行・報告方法になるわけではありません。テストターゲットの構成と移行ガイドを確認し、まず小さなテストで挙動を確かめてください。
Swift TestingのテストでXCTestの断言が失敗したのに表示されない場合は？
そのテストがSwift Testingで実行されているか、呼び出した補助関数の中でXCTestの断言を使っているかを確認します。次に、実行結果の警告や診断を読み、相互運用モードと照合してください。表示されないことだけを根拠に、断言を一括置換するのは避けます。
XCTestの中で#expectを使うと問題になりますか？
#expectはSwift Testingの機能なので、XCTestのテストから呼び出す場合はフレームワーク間の相互運用として扱われます。Swift 6.4ではこの利用が案内されていますが、診断の出方はツールチェーンや設定に左右される可能性があります。テストが実行されたか、相互運用の診断があるかを先に確認してください。
Swift 6.4への更新後、相互運用モードはどう確認しますか？
使用中のSwiftツールチェーンとPackageのswift-tools-versionを記録し、Appleの移行ガイドでモード名と適用範囲を照合します。環境変数で指定する場合は、公式文書にある名前と値を確認してください。設定方法を推測で補わず、実行環境も点検します。
修正後の結果を検証する
変更前後を比較できるように、成功するケースと失敗するケースを用意します。成功側が引き続き成功し、失敗側の断言が結果に記録されることを確認してください。どちらか一方だけでは、断言の問題が直ったのか、テストそのものが実行されなくなったのかを区別できません。
Xcodeのテスト機能に関する公式案内も参考にしながら、設定を変更した後は同じテストを実行して比較します。ツールチェーン、Xcode、swift-tools-version、相互運用モード、問題の呼び出し、成功・失敗それぞれの結果を記録すれば、授業の提出前にも原因をたどり直せます。
確認結果から次の対応を決める
次のチェックリストで、コードを直すのか、設定を再確認するのか、実行環境を見直すのかを選びます。
-
[ ] テストが実行されていない、スキップされている、またはビルドに失敗している
→ 相互運用モードはまだ変更せず、テストターゲット、実行先、ビルドエラーを先に直します。 -
[ ] テストは実行され、別フレームワークの断言を呼ぶ箇所が見つかった
→ 呼び出し元とヘルパー関数を確認し、移行ガイドに沿って最小のテストで結果を検証します。 -
[ ] 警告や診断があり、ツールチェーンまたは
swift-tools-versionも更新されている
→ 現在の設定を記録したうえで、公式文書にあるモードの対象範囲を照合します。診断を消すだけの目的で、より緩いモードを選ばないでください。 -
[ ] 同じ成功・失敗テストを実行しても、Xcodeでプロジェクトを動かせる環境がない
→ まず学校のMacを使えるか確認します。短期間だけ実プロジェクトの確認が必要なら、RUVCLOUDのMac環境で利用期間や接続方法を確かめます。 -
[ ] 長時間の継続利用や物理機器との接続が必要
→ レンタルが適するとは限りません。購入や学校設備の利用と、料金案内にある利用条件を比べてください。
学校の端末ではソフトウェアを追加できないことがあり、WindowsだけではXcodeを使ったAppleプラットフォーム向けの確認ができません。一方、Macの購入には初期費用がかかり、macOS仮想マシンは使用するパソコンや構成によって導入・実行条件が異なります。まずは同じ成功テストと失敗テストで相互運用の結果を確かめ、必要なのがXcodeで動くMac環境だと分かった場合に、学校の設備、購入、RUVCLOUDのレンタルを課題の期間と利用条件に合わせて比較してください。