趣味のゲームに1000以上のテスト ― むだ？

私たちのプロジェクトには、今や1000をはるかに超える自動テストがあります。サーバー側に約990、Unity クライアントに約120です。家族のプロジェクトにしては、やりすぎに聞こえるでしょう。でも逆なのです。その理由をお話しします。

テストは、私たちの2人目の開発者です。ひとりで作っているので、コードレビューで「ちょっと待って、それだとクラフトが壊れるよ」と言ってくれる人はいません。テストが、その同僚です。レシピ、酸素、空腹、生き物の行動、ワールドのパスワードなど、ゲームのしくみのすべてに、変更のたびに実行されるテストがあります。こわがらずにリファクタリングできることが、本当の成果です。

じゃまにならない速さ。15分もかかるテストは、だれも実行しません。だから私たちの CI のゲートは、2段階です。プルリクエストのチェックは、速いテストで3分ちょっとで終わります。完全で遅いテスト一式は、そのあとに走ります。こうして、開発のサイクルを軽く保ちつつ、カバー範囲も失いません。

Unity のテストは、それだけで一つのテーマです。クライアントのロジックは、動いているエンジンの中ではテストしにくいものです。私たちの工夫は、クライアントの中核のロジックを、Unity なしで動く専用のライブラリに入れることです。それを、普通のコードのようにヘッドレスでテストします。本当にエンジンが必要なものだけが、EditMode/PlayMode のテストとして動きます。

警告は、エラー。私たちの CI は「warnaserror」でビルドします。コンパイラの警告は、どれもビルドを失敗させます。細かすぎるように聞こえますが、いちばん大事な警告がいつのまにか埋もれてしまう「警告の墓場」を防いでくれます。

正直な結論：テストを書くのに、開発時間のおよそ5分の1がかかります。でも、直した機能は、直ったままでいてくれます。そして、仕事のあとの夜に息を吹き返すプロジェクトにとって、週末の機能が火曜日の機能を壊していないという確信ほど、価値のあるものはありません。