Swift Digest
この記事の要点
- Google Summer of Code（GSoC）2025 の Swift プロジェクトの成果を紹介するシリーズの第 4 弾（最終回）で、Kelvin Bui さんが取り組んだ「Swift Testing のコンソール出力の改善」を取り上げています。
swift testの従来の出力は、一直線に並ぶイベントの羅列で、大規模なテストスイートでは失敗箇所を見つけにくく、テストとスイートの階層関係も把握しづらいという課題がありました。- 成果として、テストの階層を木構造で表示する Hierarchical Summary と、失敗ごとに完全修飾名・エラーメッセージ・ソース位置（
file:line）をまとめる Detailed Failure Report を備えた、新しい 2 段階のコンソールレポーターが設計・実装されました。
プログラムの目的
GSoC は Google が運営する年次プログラムで、メンターと組みながらオープンソースプロジェクトへコントリビューションすることで、新しい開発者に実践的な経験を提供することを目的としています。2025 年も Swift プロジェクトが参加し、4 件のプロジェクトが実施されました。この記事はそのシリーズの第 4 弾（最終回）で、Kelvin Bui さんが Stuart Montgomery さんのメンターのもとで取り組んだ、Swift Testing のコンソール出力の改善を紹介しています。
swift test の従来のコンソール出力は機能的ではあったものの、大規模で複雑なプロジェクトでは次のような課題がありました。
- 失敗箇所を見つけにくい: 大きなテストスイートでは、重要な失敗メッセージが大量の成功出力に埋もれてしまい、テスト全体の健全性をすばやく把握するのが困難でした。
- 構造の欠如: フラットなログ形式のため、テストと親スイートの関係、特に多くのモジュールがネストしたプロジェクトでの構造が分かりにくいものでした。
このプロジェクトの目標は、情報量が多く直感的に読める高度なコンソールレポーターを作り、これらの課題を解決することでした。
成果
階層的なテスト表示（Hierarchical Summary）
新しいレポーターは、スイートとテストの関係をインデント付きの木構造で可視化します。Unicode の罫線文字（box-drawing characters）を使い、モジュール・スイート・個々のテストのネスト構造を表示します。罫線文字に対応していない端末向けには ASCII へのフォールバックも用意されており、Windows・Linux・macOS の各端末や、対話的でない CI 環境でも崩れずに表示されます。
失敗は木構造の中で「サブノード」として表示され、失敗の詳しい説明がそのテストの直下に現れます。各スイートの出力の末尾には、インデントを 1 段戻した（out-dented）サマリ行が置かれ、そのスイートの結果がきれいに締めくくられます。
失敗の詳細レポート（Detailed Failure Report）
加えて、専用の FAILED TEST DETAILS セクションが設けられ、失敗ごとに次の情報がまとめられます。
- テストの完全修飾名
- 詳細なエラーメッセージ
- 失敗が起きた正確なソース位置（
file:line）
木構造の中には短いメッセージだけを置き、完全な情報はこの詳細セクションにまとめるという 2 段構えにすることで、木構造が情報過多でうるさくならず、かつ必要な文脈も失われないよう調整されています。
シリアライズに基づくアーキテクチャ
このレポーターは、テストイベントを ABI.EncodedEvent というシリアライズされた形式で受け取って処理する設計になっています。まず最初に流れてくるテスト探索（discovery）イベントを取り込んでテストプランのメモリ上の表現を組み立て、以降のイベントは ID をキーにテストの詳細を引き当てる、という流れで動作します。
この設計は、テストの実行を別プロセス（スーパーバイザープロセス）が監督する将来の構成を見据えたものです。プロセス内のオブジェクトグラフに依存せず、シリアライズされたイベントストリームを介することで、堅牢性が高まり、プロセスをまたいだ実行（harness 形式の実行）が可能になります。
学び・今後
Kelvin さんは、シリアライズと ABI を前提に設計し直したことで、プロセス境界をまたぐためには安定したエンコーディングの取り決めと、テストのメタデータを引き当てる明示的なロジックが必要になるという、デカップリングの価値とトレードオフを学んだと振り返っています。あわせて、結果を集約するスレッドセーフなコレクタの実装ではロックの粒度とスループットのバランスが重要だったこと、罫線文字の ASCII フォールバックでは「最も非力な端末をまず想定し、そこから段階的に拡張する」設計が有効だったことを挙げています。
プロセス面では、早い段階で Swift Testing ワークグループにライブで発表したことが設計上の前提を素早く洗い出すきっかけになったこと、作業を骨組み → ABI への切り替え → UI 機能という小さな PR に分割したことでレビューが進めやすくなったことを学びとして述べています。あわせて、メンターの Stuart Montgomery さん、詳細なアーキテクチャ面のフィードバックをくれた Jonathan Grynspan さん、そして Swift Testing ワークグループやフォーラムでフィードバックをくれたコミュニティへの謝辞を述べています。