Unity Test Framework を使用してゲームコードをテストする

If you are new to the Unity Test Framework (UTF), read the documentation for an introduction. In brief, the UTF enables Unity users to test their code in both Edit Mode and Play Mode, and also on target platforms such as Standalone, Android, iOS, and others.

UTF uses a Unity integration of the NUnit library, which is an open-source unit testing library for .Net languages. For more information about NUnit, see the official NUnit website and the NUnit documentation on GitHub. 

You might also find these blog posts informative:

Performance benchmarking in Unity: How to get started

Testing test-driven development with the Unity Test Runner

Another related solution to learn about is Backtrace, an error management platform that enables you to capture crashes and exceptions and fix them quickly. Watch this Unite Now session for an in-depth introduction. 

Test Runner API（以下の API）を使用して、あらゆるスクリプトからテストをプログラムで実行できます。編集モードか再生モード、またはその両方で実行されるテストの一覧を、実行することなく取得できます。登録/登録解除のコールバックを、各テストの開始と終了およびテストサイクル内の各レベル（全テストアセンブリ、個々のテストフィクスチャごと、テストクラスおよびテストごと）に接続できます。 

各テストの開始時点で、これから実行するテストルートに関する情報が得られます。テストが終了すると、テスト結果が表示されます。 

UTF を Unity エディターの再生モードで実行するのに加えて、新しいカスタマイズポイントによりターゲットデバイス上で実行できます。これはプレイヤーをビルドする前に呼び出されます。プレイヤービルドオプションを変更して、たとえばテストの実行設定を変更したり、ビルド場所を指定したりできます。

ローカルマシンに接続されていないターゲットデバイスでテストを実行する必要があるときは、ビルドプロセスと実行プロセスを分割すると便利です。たとえば、ターゲットデバイスがクラウド内にある（またはクラウド内の複数のデバイスである）場合などがあります。 

これを実行するには、まずプレイヤービルドのテストプロセス自体をカスタマイズする必要があります。その方法を紹介します。 

• プレイヤーがビルドされてすぐにテストが起動して実行されないように、AutoRun を無効にします。 
• （デフォルトで保存される）システムの一時フォルダーではなく、既知の場所に保存します。 

次に、（コールバックインターフェースを使用して）プレイヤー側にカスタム結果レポートを追加し、すべての結果をキャプチャーして XML ファイルなどプロジェクトに対応する形式で保存します。 

ビルドと実行を分割する方法については、次のコード例を参考にしてください。Unite セッションでは、Richard Fine がこのアプリケーションの両方の部分（ビルドと結果レポート）のコードを順を追って説明しています（6:28 から）。

ビルド：

実行： 

開発者が検証を記述すると、結果がコンソールウィンドウに表示されるものの、メッセージが絶え間なく流れる中で見失ってしまうことも少なくありません。検証結果をテストスイートで取得し、エディター内の専用の場所で明確に示されると便利です。これは、メニュー項目用の特定のテストを起動することで実現できます。  

まずは MenuItem に関連付けられたメソッドから始めます。他のエディター拡張メニュー項目で実行する方法とまったく同じです。そのメソッドにより、ScriptableObject コールバックオブジェクトが作成されます。正規のクラスの代わりに ScriptableObject を使用します。これにより、コールバックはそのまま維持しながら、テストがさまざまなこと（ドメインの再ロードを引き起こすなど）を実行できるようにします。ScriptableObject が有効になると、コールバックに登録されます。無効になると、登録が解除されます。 

次は、フィルターをセットアップします。MenuItem に対するテストを起動するときは、特定のカテゴリーやグループを対象にテストを実行する必要があることがよくあります。フィルターを使用すれば、テストを非同期的に実行できます。テストは複数のフレームにわたって実行され、テスト中に UnityTest、UnitySetUp、UnityTearDown によりエンジンループをティックするよう指定できます。テストが終了して RunFinished が登録されたら、メッセージを表示するか結果ウィンドウを開くように設定できます。ご自身のワークフローに合ったほうをお選びください。

以下のコード例をご覧ください。Richard が Unite セッションにてこのアプリケーションのコードのセットアップについて順を追って説明しています（11:50 から）。 

ビルドの前にテストを実行することはやり辛いと感じるかもしれません。ビルドプロセスではテストがコールバックから実行されることを必要としているため、エンジンの更新ループをくみ上げる機会がないからです。ただし、実際のビルドに時間をかける（プロジェクトによっては何分もかかることがある）前に、基本機能が機能していることを確認できることが利点です。 

このアプリケーションは、他の種類のビルドの前処理を実装する場合と同様に、IPreprocessBuildWithReport インターフェースを使用して実装できます。結果を取得するには、いつものようにコールバックを登録します。

ビルドの途中で再生モードに入ることはできないため、Test Runner API を使用して編集モードで特定のテストを実行できます。これらのテストは、ビルド前検証テストのカテゴリなど、カテゴリ別にフィルタリングすることで選択できます。これらのテストは同期的に実行できます。 

テストが終了したら、テスト結果を確認します。どこかでエラーが発生した場合は、BuildFailed 例外をスローすることでビルドプロセスを中止できます。 

このアプリケーションは、ResultCollector とプリプロセッサーの 2 つの部分に分けられます。このことについては、Richard によるこちらの講演にて詳細を説明しています（15:20 から）。 

Christian と Richard による Test Runner API に関するライブデモをご覧ください。セッション全体からさらに多くの QA に関するヒントが得られます。