統合テストランナーとテストの分析について

Unityでは、私たちは沢山の異なるテストフレームワーク(Figure 1 参照)と、テストスイートを使っています:

• ランタイムテスト（Runtime Tests）はUnityの公開されたランタイム用APIを全てのプラットフォームで検証するテストです。
• 結合テスト（Integration Tests）はランタイムテストで検証するのが難しい要項についてテストを行うものです - 結合テストはUnityエディターの機能やキャッシュサーバー、バグレポーターなどを含んだ検証を行うことが出来ます。
• ネイティブC++テスト(Native C++ Tests) は、ネイティブコード層の機能をスクリプトレイヤーを介すことなく直接検証するテストです。
• グラフィックテスト(Graphics Tests)は描画に関するテストで、比較対象となる（あらかじめ用意された）画像データとテストコードによるレンダリング結果を比較して、正しい描画結果になっているかを検証します。
• ほかにも、パフォーマンステスト(Performance Tests)、ロード処理テスト(Load Tests)、IMGUI(OnGUI)のテストなど、沢山のテストスイートがあります。

全体的な構造についてザックリと説明すると、全てのテストはそのテストが使用するフレームワーク毎に異なるサブセットとしてグループ化されています。しかしながら、これらのテストはさらにプラットフォーム、実行頻度、実行時間や他のいくつかの基準によってさらに分類されます。

これほど多くのテストフレームワークやテストランナーを管理するのは簡単ではありません。ですので、1年ほど前から統合テストランナー（Unified Test Runner, UTR）というものを開発しました。統合テストランナーは全てのテストを実行する統一的なエントリポイントとして機能します。UTRはどのフレームワークのテストを実行する時でも玄関口(facade) となります。（Figure 2参照）UTRを開発したことで、だれでも、どのテストでもコマンドラインから一様に実行できる環境が実現しました。

すべてのテスト実行結果(artifacts)はフレームワークによらず同じ場所にコピーされて集められ、統一的なルールでグループ化・整頓されます。UTRはさらに:

•  -testfilter=TestName とオプションをつけることで、実行するテストを横断的にフィルター出来ます。
• テストの実行経過を全てのテストスイートについて同じ形で取得できます。

UTRははじめ、開発者のローカル環境で主に利用されていました。しかしながら私たちは統合テストランナーをビルドファームでも使われてほしいと考えていたので、その後ビルドファーム用に利用できるための改善を始めました。ここでのポイントは、テストがローカル環境で実行されるのと同じようにビルドファームでも実行されることでした。これは別の言い方をすると、仮に何かがビルドファーム上で失敗したとき、ローカル環境でこれを簡単に再現できるようにする、ということです。そういう風にしたかったのです。

時を経るにつれ、UTRは確実にUnity社内でテストを実行する唯一のエントリポイントになっていきました。この変化がUTRに、テストの実行に続くもう一つの重要なタスクを与えました - ローカル・ビルドファームを問わない、テスト実行結果とデータの収集です。UTRはテストの実行が終わると、テスト結果とデータをWebサービスにレポートします。これが、テストデータ分析ツール「Hoarder」が産まれた瞬間でした。Hoarderはテスト実行結果のデータを収集・蓄積し、これらのデータへのアクセスを提供します。開発者はHoarderを通して、テスト結果を集約した統計情報や、個別のテスト実行結果まで掘り下げた情報を取得することができます。（Figure 3参照）

このデータからは、私たちは沢山の貴重な発見をした他、時に適切な情報に基づく決断をすることが出来ました。これについては次のブログでさらに深掘りしてお話ししたいと思います。