この記事でのバージョン
Unity 2017.4.6f1
はじめに
Unity Test Runnerがコードの挙動確認やトライ&エラー環境としても使えるという記事を見かけまして、
ブログを書く時によく挙動確認を行うので便利そうだな〜と思い、試してみました!
どういう事かちょっと分かりにくいかもしれないので、先に具体例をあげます。
ようはちょっとしたコードをエディタを実行せず試したい。という話です。
using NUnit.Framework;//Testを使うために必要 using UnityEngine; public class TestSampleClass { [Test] public void TestSampleMethod() { Debug.Log("テスト!"); } }
また、結論も先に言ってしまうと、個人的には挙動確認やトライ&エラー環境として
Unity Test Runnerを使うのは微妙だと思いました。(使えない事もないがそこまで利便性はない感じ)
なお、元記事でもUnityのテストに関する事だと勘違いしてる方を散見したので先に断っておくと、
この記事はテストを行う記事ではありません。
Unity Test Runner
そもそもUnity Test Runnerとはなんぞや?という話からですが、
公式のマニュアルによると以下の通り。
The Unity Test Runner is a tool that tests your code in both Edit mode and Play mode, and also on target platforms such as Standalone, Android, or iOS.
Google翻訳----------
Unity Test Runnerは、編集モードと再生モードの両方で、またスタンドアロン、Android、またはiOSなどのターゲットプラットフォームでコードをテストするツールです。
ざっくり言えば、Unityでテストを実装&実行するためのツールです。
ついでにテストとはプログラムに問題ないかをチェックし、品質を保つためのプログラムの事です。
もちろん、このテストのプログラムも基本的には人間が書きます。
なお、Unity5.3あたりではEditor Test Runnerという名前だったっぽいです。
今回はこのUnity Test Runnerをテストのためでなく、コードの動きを確認するために使います。
ちなみにUnity Test RunnerのウィンドウはWindow->Test Runnerから開きます。
EditMode
まずはEditMode、つまりUnityエディタを実行してない時の話からです。
例えば以下のようなプログラムを試そうと思った時、Testという属性を付けるだけで準備完了です。
なお、コードはEditorフォルダ以下に置く必要があります。
using NUnit.Framework;//Testを使うために必要 using UnityEngine; public class TestSampleClass { [Test] public void TestSampleMethod() { Debug.Log("テスト!"); } }
実行出来るようになると、ウィンドウにクラスとメソッドが表示されます。
あとはRun Allで全て実行するか、
RunSelected(ダブルクリックでも可)で選択しているものだけを実行するだけです。
デフォルトで処理時間が表示されるのはちょっと嬉しいポイントです。
ただ、今回の趣旨は挙動確認やトライ&エラーなので、
MenuItem(+ショートカット)で十分な気がします。
using UnityEngine; using UnityEditor; public class TestSampleClass { //Test -> Sampleを選択すると実行(gキーを押すだけでも実行) [MenuItem("Test/Sample _g")] public static void TestSampleMethod() { Debug.Log("テスト!"); } }
一応、複数のコードを同時に試したい場合、
試すメソッドを任意切り替えたい場合はUnity Test Runnerが使えるかもしれません。
もしくはコードのチェックをする時ですが、
それだとただのテストで、今回の趣旨とは逸れるので割愛します。
PlayMode
次はPlayMode、つまりUnityエディタを実行している時の話です。
なお、PlayModeを有効にすると、
ビルド時間とビルドサイズ後のファイルサイズが増えるので注意が必要です。
ではEditModeの時同様、ログを表示するだけのプログラムを試してみます。
Testという属性を付けるのは同じですが、GameObjectを生成し、コンポーネントをAddするために
テスト実行用のクラスが必要になります。
なお、コードはEditorフォルダの外に置く必要があります。
using NUnit.Framework;//Testを使うために必要 using UnityEngine; public class TestSampleClass : MonoBehaviour { public void Start() { Debug.Log("テスト!"); } } /// <summary> /// テスト実行用クラス /// </summary> public class SampleClasstTest{ [Test] public void Test() { new GameObject("TestSampleClass").AddComponent<TestSampleClass>(); } }
するとEditMode同様、ウィンドウにクラスとメソッドが表示されます。
実行方法もEditModeも同じです。
EditModeと違うのが、実行時にテスト用のシーンを作成し、そこで実行している事です。
なお作成されたシーンは実行後に削除されます。
当たり前ですがシーン上で実行しているので、エディタを再生して試すのと実行速度は変わりません。
なのでテスト用のシーンを作る必要が無くなるが、
テスト実行用のクラスを作る必要が出る。という感じで一長一短です。
おわりに
という事で少なくとも挙動確認やトライ&エラー環境としてUnity Test Runnerを使うのは微妙でした。
もちろん、本来の使い方であるテストツールとしての優劣ではありませんので注意してください。
ただアンケートを取った所、良かったと言う人もいるようなので
気になる方は一度試してみる事をオススメします。
Unity使いの方にアンケートです!以下の記事を試しましたか?
— カン神巫女 -KAMIKO- (@Kan_Kikuchi) 2018年7月3日
Unity使いは全員Unity Test Runnerを使え!爆速のトライ&エラー環境だぞ! https://t.co/rV42oSZAww#Unity #アンケート
やっぱり自分で手を動かさないと分からない事も多いですしね!