デジタルパペットのプロジェクトにUnity Test Runnerを導入してみました。
導入した経緯
新機能を付けようと思ったが、数年ぶりのプロジェクトだったので、どういうテストをいつもしていたか忘れてしまい、どうしようかとおもっていたら、Unityのテストがあることがわかったので、せっかくの機会なので導入してみようとなりました!
メリット
- 実装中のバグの発見がとても早かった
- テストボタン押すだけなので、手動よりも楽!
- なんかうれしいー!
デメリット
- 効果的なところにテスト入れないとダメかもしれません
- テストの実装コスト
- 最初導入するまでちょっとつらいかも?
結果
Unity Test RunnerにはEdit Mode(単体テスト)とPlay Mode(結合テスト)があって
Play Modeのテストの方が効果が高かったです (※ gifはPlay Modeです)
デジタルパペットはパズルゲームなので同じコマンドを入力すると同じ結果になります。
なのでコマンドを入力して、同じ結果になるかをテストすれば、コードを変えてもテストコードを変えなくても済む仕様に強いテストコードが出来上がります。
どこをテストすべきか?
コードを変更しても、テストコードを変更しなくてよいテストコードが良い気がします!
必ず同じ結果になるパズルゲームなので、結果に対して、テストコードさえ書けば、仕様の変更に影響を受けにくい、テストコードのできあがりです。
個人開発なので無理をしないテストコードが僕は好きです。
どういう書き方のテストコードが良いか
これは他の言語と同じで、テスト項目ずつ、メソッドをつくる
できれば、フレームワークの機能を使って、テストコードを楽に生成できるテストケースを使うのがベストだと思います。
感想
テストコードは最小の労力で程々の効果を得れるのが僕の理想なので、結果が変わらないようなゲームを作っている方はオススメです!
次回はサンプルコードをのっけたいと思います