テストを導入してみた話

はじめに

SHABOMはハッカソンで開発したプロダクトを、リリースまで目標をシフトして作り込んできたプロダクトです。もちろんハッカソンに出場したときにはテストコードは書いていませんでした。

これは、ハッカソンなので新しいツールは積極的に使いたかったのですが、何よりも完成させないといけないので外に出る品質的な部分に直接関係しないテストツールはハッカソン中に導入していませんでした。

一方で、リリースを目指した開発を始めたとき、動作チェックのイテレーションが非常に遅いことに気づきました。理由は簡単で、例えばエラー時にメッセージダイアログを表示する機能のチェックがしたいときはサーバ側の修正をして、エラーが起きる環境を意図的に作った上で、アプリをビルドしてログインして、既定の操作をしてエラーを発生させるという手順が必要だったからです。

コード設計は意識していたため、メッセージダイアログの表示自体は簡単にテストできる状態でした。なのでリリースを目指してアプリの質を担保するためにテストツールを導入することにしました。

Unity Test Runnerとは

今回導入したテストツールはUnity Test Runnerというツールです。これはC#のNUnitを元にUnity向けに開発されたテストツールでEditorモードと、Playモードの二種類があります。

Editorモードは、ゲームの再生を必要とせず非常にスムーズにテストを実行することができます。単純なロジックが正しく動いているかなどをチェックするだけならこちらで十分だと思います。コルーチンの動作チェックをしたい場合などは次のPlayモードを利用するといいです。

Playモードは、ゲームの再生を行った上でテストを行います。こちらは若干再生する際のビルド時間はありますが、実際に再生して手動でテストを行うより遥かに効率よくテストができます。また、Editorモードと違い、コルーチンでnull以外を返すことができます。非同期通信などが必要なテストケースの場合はこちらを使うといいです。

良かった点

コード設計を考えてから開発していたため、比較的モジュールが切り分けられていてテストはしやすい環境でした。だからこそ、手動でチェックしていた分の時間ロスは大きかったと思います。

Unity Test Runnerを導入して良かった点は、機能単位でテストを実行することができますし、一度テストコードを書いてしまえば、誰でも、さくっとテストを実行することができるので開発全体の効率が上がったと思います。

改善点

Unity Test Runnerではテスト関数に様々なAttributeを付加することができるのですが、今回はまだまだ触り始めてすぐということで、基本的なことしか使っていません。今後はUnity Test Runnerの調査も含めて、もっと様々なことができないかを調べて、より質の担保がしやすい開発環境を作っていければと思っています。

最後に

テストツールを導入して結果としてテストが楽になりましたが、テストツールはあくまで仕組みですし、必ずしも使わないといけないわけではないと思います。質を担保する手段の一つとしてテストツールがあるわけで、テストツールを使うことが目的にはならないよう、そこは柔軟に考えて今後開発環境を考えていきたいと思います。