【Unity】テスト範囲は設計と照らし合わせて(フェーズもあるよ)

昨日書いた記事で、『【Unity】ちょっとコードを書いたらすぐテストしてバグを積み立てない』なんて形でなるべくこまめにテストをしようね、なんて語ったのですが、この記事ではテストの話題をちょっと深掘りして、テストはなにをもとに行うのかと、テストフェーズについて触れてみたいと思います。

エクスプラボ

【Unity】ちょっとコードを書いたらすぐテストしてバグを積み立てない

https://ekulabo.com/small-test

コードを少し変更したらすぐにテストすることをおすすめします。細かい単位でテストしていくことで、バグの解決が簡単になります。なるべく解決が容易なうちに修正しておくとスムーズにゲーム作りを進められます。

IT系の会社で働いたことのある人だったら既に知っている内容なので、復習がてらご覧いただくか、あるいは別の作業に戻ってもらっても良いと思います。

ここではIT系の会社にはいたことないけど、Unityでゲーム開発を始めた人向けに解説していきます。

テストのフェーズについて

ゲーム開発も含めてですが、プログラミングを行ってなんらかの機能を作ったときにはテストを行います。テストは想定した通りの動きになっているか確かめること。書いたコードはなかなか思った通りに動くことはなく、なにか抜けていたり、処理の順番が意図した通りでなかったりと、正しくない状態になっていることがあります。

こうした正しくない状態になっていることを知って、修正して正しい状態にしていくのがテストの役割です。

テストにはいくつかのフェーズ(段階)があります。ざっくり分けると以下のようになっています。

実施の順番は主に単体テスト、結合テスト、システムテストの順です。小さいものから大きなものに進んでいくイメージです。

細かいバグなどは単体テストで修正しておくと、後のテストでもっと広い視野の確認ができるようになるんですね。

何をもって「想定される動き」なのか

テストは想定される動きになっているかどうかを確かめるもの。じゃあ何をもって「想定される動き」と言っているのか、というのは当然の疑問だと思います。

「想定される動き」というのはゲームの設計のこと。

ゲーム全体の進行だったり、キャラクターの操作のような細かいことだったりと、プログラミングしたりエディタで作業したりする前に決めておく振る舞いが設計です。設計通りにプログラミングした後、本当にこの設計通りになっているかどうかを確認するのがテストの役割なんです。

ITのプロジェクトだったら設計がとても重要で、設計書もちゃんとしたフォーマットのものを用意したりするのですが、個人でゲーム開発をしているのであればフォーマットにこだわらない方がスムーズに決めていけると思います。私の場合は白い紙を用意して、そこに手書きでゲームのルールだったりストーリー、キャラクターのイメージ画像、振る舞いなどを書いていきます。自分だけが見るので、自分が分かればいいやの精神でこうしています。

人と一緒にゲームを作るなら流石に他の人にも分かるように設計書を書きますが、大事なのは読んだ人が分かる形になっていることです。

また、開発していて設計を変えた方が良いこともあるので、そうなったら設計のメモや設計書も直しておきましょう。

テストの内容も決めておこう

テストは設計をもとに行っていきます。このとき、テストの内容もなんらかの形で用意しておくと何を確認したらいいのかわかりやすくなると思います。

ITの会社だったらテストケースと呼ばれる、何を確認するのかをまとめた文書を用意します。例えば以下のような項目があります。

• 何を確認するのか
• どうやって確認するのか
• OKとする基準はなにか
• 誰がテストしたのか
• いつテストしたのか

これはテストした内容が他の人にもちゃんと分かるように作っていて、基準をクリアした証拠写真としてスクリーンショットも残す必要があったりします。この証拠写真は「エビデンス」とも呼ばれています。

個人でゲームを作っていると、これらの項目をしっかりとしたフォーマットで残すのは大変なので、何をいつ確認した、くらいの情報が分かるようにしておくと良いと思います。

大事なのは設計に沿って動きを確認していくこと、そしてそれを記録しておくことです。

単体テストについて

テストのフェーズとして挙げた単体テストでは、スクリプトに記載したクラスやメソッド単位での確認を行います。引数のあるメソッドであれば、期待される値が渡されたとき、期待していない値が渡されたときの処理を確認しますし、if文の分岐は正しく動いているか全て確認します。

細かい確認が多くなって「うわーめんどくさいなぁ……」なんて思ったりもしますが、この単体テストで確認しておかないと、後のテストで思わぬバグの原因になったりもするためここでやっておくのが一番楽です。

Unityの場合、スクリプトのファイルを保存したタイミングでコンパイルを行ってくれて、構文チェックなどはすぐにやってもらえるので、そうしたエラーはすぐに気付きやすくなっています。

実際にゲームを実行するのもボタンひとつで簡単にできるので、どんどんテストしていきましょう。

結合テストについて

結合テストは複数のモジュール(機能)にまたがるテストです。例えば主人公が敵キャラに触れたとき、主人公のHPを減らしたり、敵キャラのモーションが変わったりと、複数のオブジェクトで相互作用がある部分について確認していきます。

個々のスクリプトについては単体テストで確認をしておいて、複数のスクリプトにまたがる処理をこのフェーズで確認できるとスムーズにできると思います。

ある程度慣れている人だと、主人公のスクリプト、敵キャラのスクリプトを一気に更新して結合テスト的に確認してしまう場合もあります。ただ最初から複雑にすると混乱しやすいので、最初はなるべく小さい範囲でテストをしてくのが良いと思います。

システムテストについて

システムテストのフェーズではゲーム全体の動きを確認します。ひとつのゲームとして動かしてみて、設計してある通りの動きになるかどうかを確認していきます。テストプレイという呼び方がされることもあります。

ゲームが思った通りに進行していることをここで確認していきます。全体が動くようになってからゲームバランスの調整を行っていくと確認しやすいかもしれません。

まとめ

このページではテストをする際なにをもとにするか、そしてテストのフェーズについて触れました。

テストについては設計をもとに確認する内容を決めていきましょう。また、テストの分け方を覚えておくと開発も進めやすくなると思います。

分け方とか名前は最初は覚えにくいのですが、何回かゲームを作ってると「あ、この部分が単体テストだな」と肌感覚で分かるようになると思います。もし友達にIT系の人がいたら聞いてみるのも良いかもしれません。