【Unity】”実機に出力したアプリ”の動作テストを自動化する

今回はテストランナーを利用したアプリの動作確認についてです。

テストをUnityで
- ある程度の時間が必要な処理のテストも可能にはなった
実際の動作を確認するPlaymode Test
実機で動作を確認する
実際のやり方
感想
関連

テストをUnityで

f:id:tsubaki_t1:20171211232820j:plain

UnityはUnity 5.3辺りにTest Runnerをエディターの基本機能に統合しました。

これを活用すると、何らかの問題を起こしたときに何処がトラブルをおこしているのか、そしてソレ以前に内容を常に監視することでトラブルが発生する事を未然に防ぐことが期待できます。

tsubakit1.hateblo.jp

テストを記述する事は面倒ですが、実際これを書きながら開発すると、コードを変更したときの安心感があります。少し。

ある程度の時間が必要な処理のテストも可能にはなった

またいつ頃か（たしか5.6辺り？）テストに擬似的なコルーチン処理を利用した処理待ちも利用することが可能になりました。以前はダウンロードの処理待ちといった実装の動作を確認することは出来ませんでしたが、これが可能になった訳です。

例えば以下のような処理で、エディター内で実際にコンテンツをダウンロード出来るか確認できます。

gist.github.comあくまで擬似的なコルーチンで、nullを行うとそのフレームをスキップするという動作だけな点には注意が必要ですが。

実際の動作を確認するPlaymode Test

さて、テストにはPlay Modeという項目があります。
こちらはEditor Modeと異なり「実際にゲームを再生して動作を確認する」特徴があります。

何が良いかといえば、シーンを実際にロードして動作を確認することが出来るという点です。再生してステージやシーンをロードし、コマンドを与えて実際の動作を確認する訳です。

f:id:tsubaki_t1:20171211233654g:plain

実機で動作を確認する

またPlayModeの重要な機能は、Run all in Playerの機能です。

この機能は実際にゲームをビルドしテストを行う事が可能になっています。

特にこの機能で重要なのはネットワークやプラグインまわりのテストでしょう。

Unityは基本的にはMono上で動作しますが、ネットワークなどの処理は端末のネイティブ機能をりようしているみたいです。そのため、エディターでは動くが実機では…といった事が往々にして起こります。

また特にスマートフォン向けに開発する場合、パフォーマンスの特性がエディター（PC）と異なるため様々な所で差が出てしまいます。

その点から、実機向けに出力して動作を確認する機能は、わりと嬉しい機能の一つです。

実際のやり方

やり方を紹介します。

無効化されているTest Runner（PlayMode）の有効化

まずメニューアイテム > Window >Test Runnerで Test Runnerを開き、Play Modeを選択すると、Enable Playmode testsと表示されるかもしれません。

ボタンを押して有効にして、エディターをリスタートします。

f:id:tsubaki_t1:20171211234734j:plain

なお、Playmode testが有効になっているとビルドサイズが増える他、ビルド時間が伸びるそうです。不要な場合はTest RunnerのコンテキストメニューからDisable Playmode test runnerを選択する感じです。

PlayModeの実装はランタイムの実装

まず適当にテストを実装してみます。

Testing > Playmodetest C# scriptでテストを作成します。内容は、例えばこんな感じに。

f:id:tsubaki_t1:20171211235319j:plain

なお、Playmode testはEditorフォルダ以下以外に置く必要があります。

テストの実行

あとはテストの実行です。

まずはRun All（左の通常のビルド）で実際に動作を確認します。シーンの読込やその他諸々。それが完了したら、右のRun All In Playerを選択します。

f:id:tsubaki_t1:20171211235208j:plain

これでゲームが実際にビルドされ、ビルドしたコンテンツ上でテストが行われます。

テスト完了後にはアプリは自動的に終了し、実行したテストの結果はTest Runnerのウィンドウに反映されます。

結果を受け取るには、実行するアプリとエディターが同じネットワーク内に居る必要があるみたいです。

f:id:tsubaki_t1:20171212002306g:plain

なお、ここで実行されるプラットフォームはBuild Settingsで設定しているプラットフォームです。

f:id:tsubaki_t1:20171212000719j:plain

テストをAndroid実機で確認、テスト結果をエディターで確認する。コルーチンも使えるのでシーンをロードして動作確認とかもできる #UnityTips #Unity pic.twitter.com/c06m5OOJI6
— 椿 (@tsubaki_t1) 2017年11月16日

コマンドラインから実行

最後にコマンドラインから実行を考えてみます。

マニュアルには以下の様に記載されていたので、出来ないのかなと思いましたが、

Automated tests in platform players (for example Standalone, Android, or iOS) run from the command line are not currently supported.

試してみると、下のようなコマンドで実行できました。

Unity.app/Contents/MacOS/Unity -runTests -batchmode -testPlatform StandaloneOSX -projectPath PATH_MY_PROJECT -nographics -testResults PATH_MY_PROJECT/result.xml

Unity.exe -runTests -batchmode -testPlatform StandaloneWindows64 -projectPath PATH_MY_PROJECT -nographics -testResults PATH_MY_PROJECT/result.xml

太字にしているのは大事な項目です。

f:id:tsubaki_t1:20171212005639g:plain

ところでWindowsは速攻で処理が終わってしまうのだが、ログ書込のタイミングはどうやって取れば良いんやろ。

テストの結果はエディターが受信し、-testResultsで指定したファイルに出力されます。

f:id:tsubaki_t1:20171212123440j:plain

コマンドの説明

まず-runTestsは、テストの実行です。エディターの場合は-runEditorTestですので、エディター用とは異なるコマンドです。

次に -testPlatform ですが、これがテストするテストのプラットフォームです。何も指定しなければeditmode が選択されます。プラットフォーム一覧はこちら。

なお、OSXは以前はStandaloneOSXIntelだったハズですが、気づいたらStandaloneOSXになっていました。

-nographics は無くて良いかなと思ったら実際不要でした。まぁ、テスト用のゲームをプレイする側にはグラフィックは必要ですが。

最後に-testResultsです。ここで既に存在するファイルを指定します。

Resultに指定したファイルに、指定プラットフォームで動いたテストの結果が記載されます。上書きで。

なお、-quitは使えないみたいです。というのも、テストの結果を受け取るためにエディターが起きている必要があるため、-quitを使用するとエディターがテストの結果を受け取る前に落ちてしまうためです。

-quitを使用しなくともエディターは自動で落ちるっぽいので、その辺りは問題無さそうな感じです。

感想

ということで、実機のテストをやってみました。

これ上手く使えば

ロード時間が長いシーンの検出
FPSが一定を割り込む状態の検出
ネットワークのエラー
プラグインのエラー
IL2CPP変換時の動作変化

みたいなモノもゴニョゴニョ出来るんじゃないかなと期待しています。

テラシュールブログ

旧テラシュールウェアブログUnity記事。主にUnityのTipsやAR・VR、ニコニコ動画についてのメモを残します。