これはゲーム開発エンジン Unity に関する記事です。
この記事では、私が Unity Test Runner を使ったときにつまづいた点と、その解決法などを書きます。
テストランナーと読みます。
現在は Unity Test Framework（ユニティー・テスト・フレームワーク）と呼び名が変わりましたが、同じものです。
テストランナーの概要や導入方法については、分かりやすく説明しておられる素晴らしい記事が沢山ありますので、私から説明することはせず、お勧め記事へのリンクを貼るにとどめます。
私は今のところ、エディットモードしか使っていません。
プレイモードはお試しでちょっと触っただけです。
エディットモードは、「作ったスクリプトが意図通りに動くか？」の単体テストをするのに最適です。
「作ったスクリプトが意図通りに動くか？」をテストするスクリプトを自分で書く必要があるのですが、いちいちゲームを起動して、あれこれクリックしたり、キーを押したり…といった操作を繰り返して手動でテストするより、テストランナーで自動化した方がはるかに効率が良いです。
プレイモードを使ったテストは準備に時間がかかります。
ゲームを自動操縦するボットを作ったり、テスト専用のシーンを用意する必要が出ます。
そこら辺の手間を考えると、プレイモードを使ったテストは微妙で、エディットモードでサクっと単体テストするのが主な使い道になります。
プレイモードを使う場合は、一万回ガチャを回して意図通りの結果になるか？を調べる…みたいな、人力でやるのがとても厳しいテストで使うことになると思います。
こういう、ランダムが絡む機能をテストするのは、必要な試行回数がハンパないので手動でやるよりも自動化した方が効率が良いです（多分）。
小規模プロジェクトや個人開発なら使いたいときに使えると思いますが、中規模～大規模なプロジェクトで使えるか？を考えると、権限を持ってる人の許可が必要になるので、その人たちを説得する必要が出てきます。
プロジェクトの規模が大きくなると、テスト専門のテスター（デバッガーやＱＡとも呼ばれている）チームがいます。
テストは彼らの領分なので、プログラマーがどこまで踏み込んで良いのか、彼らの合意を得るべきだという話になります。
結果として、「テストランナーでどの機能をどこまでテストするのか？」について、会議室でなが～い話し合いをすることになると思います。
プログラマーにとっては、そんなことに時間を使うのがそもそも非効率なので、政治上の問題で時間を浪費するのを避けるためにテストランナーを使わないという決断をする人も出てくるだろうなと思います。
とは言え、チーム開発でもエディットモードでサクっと単体テストするくらいならいけると思いますし、プレイモードでのテストは手動でテストするのが現実的ではない（数万通りの組み合わせになるような）テストに限定されると思います。
実際にテストランナーを使ってみて困ったことは、Assembly Definition File を使わないと「自分で作ったスクリプト」をテストできない…ところ。
しかも、この Assembly Definition File がちょっとクセモノで、扱いには注意が必要です。
トップの Assets フォルダに戻り、C# Script を新規作成します。
このスクリプトをテストランナーでテストします。
ファイル名は UnityChanKawaisugi（ゆにてぃちゃん可愛い過ぎ）にします。
私の著しいＩＱ低下が心配されそうな名前ですが、そんなことは重要ではありません。
using UnityEngine;
public class UnityChanKawaisugi
{
public void Hyahhaaa()
{
Debug.Log("ヒャッハー！");
}
}
コードはこんな感じ。
MonoBehaviour は必要ないので使っていません。
ゆにてぃちゃん可愛い過ぎクラスは、パブリックの Hyahhaaa() メソッドだけを持ってて、このヒャッハーメソッドを実行すると、コンソールに「ヒャッハー！」と表示します。
さきほど作った、ゆにてぃちゃん可愛い過ぎクラスをテストするためのスクリプトを作成します。
プロジェクトウィンドウで Assets/Tests フォルダへ移動し、テストランナーウィンドウの Create EditMode Test Assembly Folder と書かれたボタンをクリックします。
Assets/Tests フォルダに C# スクリプトが新規作成されるので、好きな名前を付けます。
今回はデフォルトの名前（NewTestScript）をそのまま使います。
新規作成した NewTestScript を開き、可愛すぎるゆにてぃちゃんがヒャッハーするコードを追加します。
で、デフォルト野郎のスクリプトを上書き保存して Unity エディタに戻ると…？
※自動更新を無効にしている場合は、Unity エディタに戻って Ctrl+R
Assets\Tests\NewTestScript.cs(16,13): error CS0246: The type or namespace name ‘UnityChanKawaisugi’ could not be found (are you missing a using directive or an assembly reference?)
型もしくは名前空間の名前 UnityChanKawaisugi が見つかりません（usingの指定もしくはアセンブリ参照を忘れてる？）。
なんかゴチャゴチャ書いてありますが、要は
「ゆにてぃちゃん可愛い過ぎクラスなんて知らねーなぁ！」
と言ってます。
Unity のスクリプトは、Assets フォルダ以下に置いたやつは、全部勝手に参照してくれます。
パブリックなクラスであれば、どのスクリプトからでも呼び出すことができます。
C言語みたいにヘッダファイルを #include しなくてもいいですし、Javaみたいに import しなくていいですし、なんかのスクリプト言語みたいに use する必要はありません。
Unity は、こういった、めんどくさい参照設定をする必要がないので、すごく楽です。
でもそのせいで、なんでもかんでもスクリプトを参照しすぎて、なにかのスクリプトをちょっと手直しすると、依存関係にあるスクリプトを全部コンパイルし直しちゃうもんだから、いちいち時間がかかる…という問題を Unity はずぅーっと抱えていました。
それを解決するために作られたのが、Assembly Definition Files(.asmdef) なのですが（以下、あすむでふ と言います）、あすむでふ を正しく使わないとこうなります。
つまり、何もしなくても勝手に参照してくれるはずのスクリプトを参照できないと言われてしまいます。
あすむでふ について知らなければ、ここで詰みます。
Assets フォルダの中に（子フォルダも含め）あすむでふ が、ひとつもないなら、あすむでふ のことを気にする必要はありません。
ただし、ひとつでもあるなら、あすむでふの知識が必要です。
あすむでふ は、アセットストアからインポートしたアセットに入ってることもありますし、テストランナーを使うと勝手に作られます。
あすむでふ をひとつも使わずにゲームを作ることはできると思いますが、あすむでふ を使わずにゲームを作るのは、作るゲームの規模が大きくなるほど辛くなります。
それなりの規模のゲームを作る場合は、必須の知識になりました。
テストランナーでテストしたいスクリプトがあるフォルダに、あすむでふ を作ります。
さっき、ゆにてぃちゃん可愛い過ぎしーえす を作ったので、そのスクリプトがある Assets フォルダで あすむでふ を新規作成します。
プロジェクトウインドウで右クリックして、Create → Assembly Definition をクリックします。
ファイル名は UnityChanChoKawaii（ゆにてぃちゃん超カワイイ）にしておきます。
ゆにてぃちゃん超カワイイあすむでふ が出来上がりました。
私のＩＱが（以下略）
テストランナーが自動作成したスクリプトと あすむでふ があるフォルダに戻ります。
Assets/Tests フォルダです。
Test.asmdef をクリックしてインスペクターを表示します。
このインスペクター内の Assembly Definition References のところにある＋（Add to list）ボタンをクリックします。
＋をクリックして追加された入力欄をクリックすると、あすむでふ 選択ウインドウが開きます。
↑の あすむでふ 選択ウィンドウで、さきほど作成した ゆにてぃちゃん超カワイイあすむでふ（拡張子の .asmdef は省略されてます）をクリックして選びます。
最後に「ヒャッハー！汚物は消毒だああああ！」と絶叫しながら、Apply（適用）ボタンを押します。
初期設定のままなら、あすむでふ を変更して Apply すれば自動でリロードされます。
手動更新の場合は Ctrl+R を押します。
あすむでふ を正しく設定し、アセットのリロードが終わった直後のコンソール
１／３くらい真っ赤になってたコンソールが、ウソのように綺麗になってしまいました。
そういえば、まだ ゆにてぃちゃん可愛い過ぎクラスのテストをしていませんでした。
テストランナーのウィンドウに戻って、Test.dll の左についてる▲をクリックすると、下に Tests という項目が表示されるので、Tests の左についてる▲をクリック、更に下に NewTestScript という項目が表示されるので、更にクリックすると、NewTestScriptSimplePasses という項目が表示されます。これをクリックして、上にある Run Selected ボタンをクリックします。
テスト用のスクリプトには、ゆにてぃちゃん可愛い過ぎクラスのヒャッハーメソッドを呼び出すコードを書きました。
ヒャッハーメソッドはコンソールに「ヒャッハー！」と表示するので、そうなればＯＫです。
Run Selected をポチっと。
次々と緑色のチェックマークがついて行きます。
緑色のチェックマークは問題なしという意味です。
ヒャッハー！
作ったスクリプトをテストランナーでテストする…という目的は果たされました。
しかし、これで一安心…と思っていると、あすむでふ から手痛いしっぺ返しを食らいます。
私はミスをしました。
分かりやすくシンプルな説明するために、わざとそうしたのですが…。
何が悪かったのかというと…。
これです。
さっき作ったばかりの あすむでふ です。
いや、あすむでふ 自体に問題はないです。
問題なのは あすむでふ がある
場所です。
Assets フォルダの直下に あすむでふ を置くと、Asset Store で購入したアセットをインポートしたときなんかに、また、なんかゴチャゴチャ言われます。
長くなるので詳しい説明は割愛しますが、それを回避する方法はあります。
要点だけを書くと、
あすむでふ を置かない。
Assets フォルダ直下でなければいいわけで、例えば、Assets フォルダに Scripts フォルダを作成し、Scripts フォルダに全てのスクリプトと、Scripts フォルダ直下にのみ あすむでふ を置くようにします。
なので、ゆにてぃちゃん超カワイイあすむでふ と、ゆにてぃちゃん可愛い過ぎしーえす を Scripts フォルダ直下に移動します。
Assets/Scripts/UnityChanKawaisugi.cs
Assets/Scripts/UnityChanChoKawaii.asmdef
こうすれば、とりあえずは安心です。
とりあえずは…。