Unityには、多くのテスト領域（図1）とテストスイートがあります。
•ランタイムテスト により、サポートされているすべてのプラットフォームで UnityパブリックランタイムAPI を テストできます。
•統合テストは、Unityエディター機能やCache ServerやBug Reporterなどのコンポーネントとの統合など、ランタイムをテストするときに見落としやすいものをカバーします。
•ネイティブC ++テストは、スクリプトを使用せずにC ++コードを直接テストするように設計されています。
•グラフィックテストはレンダリング機能を担当し、結果の画像を参照と比較できます。
•その他（パフォーマンステスト、ダウンロード、IMGUIなど）。
図1. Unityでの指示のテスト
最上位レベルでは、テストはいくつかの方向にグループ化されます。 さらなる分離は、プラットフォーム、頻度、リードタイム、およびその他の基準に依存します。 この構造により、膨大な数の制御点が得られます。 ただし、それらについては後で説明します。
このシステムを簡素化するために、約1年前、ユニバーサルユニファイドテストランナー（UTR）の開発を開始しました。 実際、これは単一のエントリポイント（図2）であり、すべての実行者とテスト領域にユニバーサルインターフェイスを提供します。 したがって、テストスイートはコマンドラインから直接実行できます。
図2.すべてのテストのエントリポイントとしての統合テストランナー
すべてのテスト成果物は1か所に保存され、統一されたルールに従ってグループ化されます。 さらに、UTRは他の機能を提供します。
•フィルターはすべてのテストに適用できます。testfilter= TestName;
•テストの進行状況に関するすべての同一レポートのセット。
最初はローカルテストにUTRを使用していましたが、ビルド環境に適用することにしました。 アイデアは、ローカルコンピューターからリリースをビルドするときに同じテストを実行することでした。 つまり、エラーが発生した場合にローカルで再作成できるようにします。
徐々に、UTRはUnityのすべてのテストの単一のエントリポイントになりました。 そして、 もう1つのタスクに使用することにしました -ローカルコンピューターとビルド環境からテストデータを収集します。 各テストの最後に、UTRは結果を専用のWebサービスに送信します。 これが、Hoarderと呼ばれるテストデータ分析ソリューションの誕生です。 そのタスクは、テストのパフォーマンスに関するデータを収集し、保存し、アクセスし、個々のテストの結果を詳細に分析できるようにテスト統計の集計を表示することです（図3）。
図3.アセンブリエージェントとユーザーはデータをHoarder Webサービスにアップロードし、分析アプリケーションによって処理されます。
データ処理の過程で、私たちは多くの興味深いものを発見し、その結果、いくつかの重要な決定を下しました。 どのもの-次の記事を読んでください。