yumeの日記： 正しいコード 3

昨日のテストの続き。

さて、Play Modeテスト（≒連結テスト）のためには非同期処理をうまいことしなきゃならなそうだな、という話であった。
テストはSetUpと実際のテスト関数で構成され、SetUpの方でやる準備に非同期処理が入る場合、実際のテストは非同期処理が終わったかを確認しなきゃならん。
そこで、昨日のコードには
await handle.ToUniTask();というコードがあったが、これはようするにUnityの非同期処理（ここではAsyncOperation）をUniTask化し、それをawaitしてくれるというコードだ。
これを実際のテスト関数にも入れればいいんじゃないか？
つまり、
・SetUpで非同期処理（handleという名前で持っておく）を走らせて、それをawaitし、完了したらplayerObject変数の中に結果を入れる。これらをUniTask setUpTaskとする。
・実際のテストで、昨日は1秒ただ待ってたところを、setUpTaskが終わるまでawaitとする。
＝各テストは、setUpTaskを待機してから実行する。

Unityフォーラムのolejuer曰く、
UniTaskを使えば、IEnumerator型の関数でyield return （なんかを待つ）の待つ部分をUniTaskにできる。そしてそのタスクの完了を待ってからそれ以下のコードに移れるらしい。
それらを踏まえて、Playerの生成・移動・視界の回転の連結テストを書いた。

Playerに必要なもろもろのSetUpが終わるまではテストを走らせないように、各テストの冒頭でyield return setUpTask.ToCoroutine();と書いておく。

そうすると、各テスト関数はちゃんと生成を待って、その後各々が必要なテストをうまくやってくれた。これでとりあえずは「テストをかける」という状態になれたかな……？

となれば、早速コードを追加していこう。壁に視界（邪眼）が阻害される機能と、壁に向かって移動命令をしても移動できなくする機能だ。

AppearCheck関数は、視界（邪眼）が次の二つの条件を満たすかを調べる：
1. 指定したターゲットが、邪眼の視野角の内側にいるか。
2. 指定したターゲットまでの直線を結び、視界を阻害するものがないか。
どちらのチェックも通った場合Trueを返す。

んん〜。これ二つのチェックを一緒くたにしちゃってるのは、あんまりよくないかな？
完全に切り分けられるんだから、分けるべきだとも思える。

それと、この関数は明らかにprivateでよさそうなのでそうしているけど、その場合テストが書けないな。まぁ、privateな関数もいずれはUnityライフサイクルか、何かしらのpublic関数から呼び出されるはずなので、前者の場合はPlay Mode Testで、後者の場合はそのpublic関数をテストすればOK、かな。

もう一つはCheckCanMove関数。これはシンプルで、目指すべきポイントに向かってLineCastして、LayerMaskで指定したLayerのColliderがぶつかった場合はとにかくfalse。
LayerMaskはどのタイミングで指定しようか迷ったけど（関数呼び出しごとに指定するか、メンバ変数にしておくか……）今回はメンバ変数に記憶させることにした……。けど、やっぱりいちいち渡した方がよかった気もするな。

しかも、この関数は個別に呼ぶのではなくて、実際の移動命令の中に埋め込まれている。まぁ移動命令をするなら普通は壁にぶつかるかをチェックするはずだから、それでいいような気もするけど、完全にバラして呼び出し元がチェック＞移動の順で命令すべきな気もする。