2026年9月6日時点のApple公式Swift Testingドキュメントでは、テストは並列実行を前提に設計されています。したがって、Swift Testingの並列テストが不安定な場合も、今週は全体の並列実行を止めず、共有状態・ファイル・ポート・Keychain・シミュレーター資源を先に隔離してください。 それでも残る範囲だけに.serializedを適用し、リモートMacの反復実行とクリーンなワークスペースで復旧を判定します。

本記事は、XCTestからSwift Testingへ移行した後にテスト順序の変化で失敗するSwift開発者、リモートMacのCIと結果収集を担当するDevOps・テストエンジニア、テストを再構成するか専用ノードを増やすか判断する開発基盤責任者向けです。

最終更新：2026年9月6日。Swift Testingの並列実行、.serialized、XCTestとの共存に関する記述は、執筆時点のApple公式資料とSwift Testing公式リポジトリで確認しています。

01

最初に失敗の種類を固定する

「ローカルでは成功し、失敗したテストを単独で実行しても成功する」という状態は、フレームワークの欠陥を直接示しません。テスト順序依存、共有資源の競合、CI Jobの同時実行、リモートMacの環境残留を分けて記録する必要があります。

最初に、次の条件を固定します。

  • 同じコミット、Xcode、macOS、テスト対象を使う
  • ローカル単独実行、CIの並列実行、失敗テスト単独実行を分ける
  • .xcresult、失敗したテスト名、実行順、開始時刻を保存する
  • テスト中のメモリ圧力、ディスク空き容量、バックグラウンド処理を記録する
  • 複数のRunnerが同じ作業ディレクトリや同じシミュレーターを使っていないか確認する

Appleのテスト結果と実行状態に関する資料に沿って結果を保存すると、単なる赤・緑ではなく、失敗した段階とテストの対応を追跡できます。

Swift TestingがCIだけで不規則に失敗する理由は何ですか。
典型的には、テストが共有する状態や資源が並列実行で重なっているためです。グローバル変数、シングルトン、静的キャッシュ、固定ファイル名、同じポート、UserDefaults、Keychain、通知監視などを確認してください。リモートMac固有の問題とは限らず、ローカルで偶然順序が固定されていただけの場合もあります。

02

役割別に修正範囲を分ける

第一段階：テスト作者は共有状態を消す

テストごとにフィクスチャを生成し、別のテストが作ったオブジェクトを再利用しない構造へ変更します。setUpやtearDown相当の準備・後処理だけでなく、非同期タスクがテスト終了後まで残っていないかも確認します。

特に危険なのは、静的な配列やキャッシュを初期化せずに使う実装です。テスト終了時にタスクをキャンセルし、通知監視を解除し、テスト専用の依存オブジェクトを破棄できる状態にします。

修正後は、実行順を変えた場合にも結果が変わらないかを確認します。単独実行だけで合格させず、同じCI入口から繰り返し実行することが停止条件です。

第二段階：アプリ担当者は外部資源を名前空間で分離する

固定された一時ディレクトリ、データベースファイル、HTTPモックのポート、UserDefaultsのSuite名、Keychainの識別子は、並列テスト同士で衝突しやすい領域です。テスト単位またはJob単位で一意な名前を発行し、終了後に削除します。

シミュレーターやUI操作は、プロセス内のSwift Testing並列実行とは別に扱います。UIセッション、画面状態、シミュレーターのブート状態が競合しているなら、Swift Testingの並列設定だけを変更しても解決しません。

注意：Keychainやキャッシュを一括削除する場合は、開発者のログイン情報や署名環境まで消える可能性があります。削除前に対象を限定し、復元方法を確認してから実施してください。

第三段階：移行担当者はXCTestとの境界を確認する

Swift TestingとXCTestは同じプロジェクト内で共存できます。Appleの移行ガイドに沿って、どのテストターゲットがどのフレームワークで実行されるかを一覧化してください。

混在時には、次の設定を分けて確認します。

  • Schemeで選択されているテスト
  • Test Planの対象と実行オプション
  • コマンドライン実行時のテスト指定
  • XCTest側の並列設定
  • Swift Testing側のSuiteやTrait

XCTestの並列実行、Swift Testingのプロセス内並列、CI Jobの同時実行、複数Runnerの同時利用は同じ概念ではありません。どの層が資源を共有しているかを、ログ上で分離してください。

Swift TestingとXCTestを混在させると並列実行に影響しますか。
影響する可能性はありますが、共存そのものが失敗原因だとは断定できません。Test PlanとSchemeで対象やオプションが異なると、ローカルとCIの実行範囲が変わります。まず実際に起動されたテストターゲットと設定を結果パッケージから照合します。

03

.serializedを使う範囲を決める

AppleのParallelizationTraitの説明では、.serializedはSuiteやパラメータ化テストなど、指定した範囲の直列化に使えます。したがって、全テストに適用するのではなく、まだ安全に分離できないSuiteを一時的に囲う使い方が適切です。

選択肢 適用条件 利点 欠点・復帰条件
並列を維持 共有資源が分離済みで、反復実行でも失敗しない 実行時間と並列性を維持できる 新しい共有状態を追加した際に再発し得る
Suite単位で.serialized 特定Suiteだけが固定資源を使う 影響範囲を限定できる そのSuiteの設計改善と解除条件が必要
パラメータ化テストを直列化 同じ外部資源をパラメータ間で共有する 衝突範囲を明確にできる パラメータ分離後は設定を外す必要がある
専用のリモートMacノード シミュレーター、署名環境、外部サービスを分けられない 他のJobから資源を隔離できる ノード管理と利用率の検証が必要

部分的な並列実行を止めるには、どこに.serializedを付けますか。
テスト関数に無差別に付ける前に、共有資源を使うSuiteまたは対象となるパラメータ化テストの範囲へ限定します。解除条件は「修正した」ではなく、クリーンなワークスペース、再起動後、同じCI入口で再発しないことにします。

全体を直列化すると赤い結果は減るかもしれません。しかし、それでは競合箇所の発見能力とCIの並列性を失います。.serializedは修正の代わりではなく、影響を封じ込める回避策として記録してください。

04

リモートMacの負荷と作業領域を検証する

CI担当者は、テストコードを直す前にノードの衛生状態を確認します。複数のパイプラインが同じMac上で動き、DerivedData、シミュレーター、テンポラリーディレクトリを共有している場合、コードが正しくても実行環境で失敗します。

次の手順で再現条件を固定します。

  1. 同じコミットを使い、クリーンなクローンを作成します。
  2. Jobごとに独立したDerivedDataと一時ディレクトリを割り当てます。
  3. 既存のシミュレーター、バックグラウンドプロセス、残留したテストサービスを一覧化します。
  4. 並列実行、問題のSuiteだけ.serialized、完全に分離したノードの順で比較します。
  5. 各実行の.xcresultとノードログを同じ成果物として保存します。
  6. Macを再起動した後にも同じ入口で再実行します。

ワークスペース隔離の設計は、Xcodeのテスト整理ガイドも参照してください。結果パッケージの長期保存が必要なら、遠隔MacのCI結果を収集・保管する手順と組み合わせ、失敗テストだけでなくノード状態も追えるようにします。

経験則：キャッシュ削除で一度だけ緑になった場合、それは修正完了ではありません。キャッシュ削除を再現手順に含めず、クリーンなクローンと独立した作業領域で再検証してください。

05

プラットフォーム責任者の判断基準

並列維持を選ぶ条件

共有状態がテスト単位で生成され、外部資源の名前空間が分離され、同じCI入口で失敗が再現しない場合は、並列実行を維持します。実行順を変えても結果が変わらないことが重要です。

局所的な直列化を選ぶ条件

特定Suiteだけが移行途中で、資源の分離に時間がかかる場合は、そこだけ.serializedにします。課題、担当者、解除条件、再確認日を記録し、全体の並列停止へ拡大しないようにします。

独立ノードを選ぶ条件

署名情報、シミュレーター、外部サービス、物理的なMac状態を他Jobと分けられない場合は、専用のリモートMacを検討します。Xcodeテストノードのワークスペース隔離や、リモートMacの並列処理能力を見積もる考え方も、ノード追加前の整理に役立ちます。

自分のPCだけでは再現しない場合、同じコミットを実行できる破棄可能なMacノードを用意し、並列と局所的な.serializedを比較してください。長期的に固定したビルド環境が必要なら、Mac miniを使ったCI構成の選択肢とレンタルの運用負担を比較します。

現在のPCで安定した再現環境を維持できない場合は、独立したリモートMacを一時的な検証ノードとして使う方法があります。並列実行、局所的な.serialized、クリーンなワークスペースを同じコミットで比較し、その結果に基づいてテストを修正するか、CIノードを調整するかを決めてください。長期の高負荷処理や物理インターフェースが必要な場合は自前のMacが適していますが、原因調査や短期のテスト環境には、既存の開発機を占有しないレンタル構成が現実的です。