Unityでは、私たちは沢山の異なるテストフレームワーク(Figure 1 参照)と、テストスイートを使っています:
全体的な構造についてザックリと説明すると、全てのテストはそのテストが使用するフレームワーク毎に異なるサブセットとしてグループ化されています。しかしながら、これらのテストはさらにプラットフォーム、実行頻度、実行時間や他のいくつかの基準によってさらに分類されます。
これほど多くのテストフレームワークやテストランナーを管理するのは簡単ではありません。ですので、1年ほど前から統合テストランナー(Unified Test Runner, UTR)というものを開発しました。統合テストランナーは全てのテストを実行する統一的なエントリポイントとして機能します。UTRはどのフレームワークのテストを実行する時でも玄関口(facade) となります。(Figure 2参照)UTRを開発したことで、だれでも、どのテストでもコマンドラインから一様に実行できる環境が実現しました。
すべてのテスト実行結果(artifacts)はフレームワークによらず同じ場所にコピーされて集められ、統一的なルールでグループ化・整頓されます。UTRはさらに:
UTRははじめ、開発者のローカル環境で主に利用されていました。しかしながら私たちは統合テストランナーをビルドファームでも使われてほしいと考えていたので、その後ビルドファーム用に利用できるための改善を始めました。ここでのポイントは、テストがローカル環境で実行されるのと同じようにビルドファームでも実行されることでした。これは別の言い方をすると、仮に何かがビルドファーム上で失敗したとき、ローカル環境でこれを簡単に再現できるようにする、ということです。そういう風にしたかったのです。
時を経るにつれ、UTRは確実にUnity社内でテストを実行する唯一のエントリポイントになっていきました。この変化がUTRに、テストの実行に続くもう一つの重要なタスクを与えました - ローカル・ビルドファームを問わない、テスト実行結果とデータの収集です。UTRはテストの実行が終わると、テスト結果とデータをWebサービスにレポートします。これが、テストデータ分析ツール「Hoarder」が産まれた瞬間でした。Hoarderはテスト実行結果のデータを収集・蓄積し、これらのデータへのアクセスを提供します。開発者はHoarderを通して、テスト結果を集約した統計情報や、個別のテスト実行結果まで掘り下げた情報を取得することができます。(Figure 3参照)
このデータからは、私たちは沢山の貴重な発見をした他、時に適切な情報に基づく決断をすることが出来ました。これについては次のブログでさらに深掘りしてお話ししたいと思います。
Is this article helpful for you?
Thank you for your feedback!