CEDEC2025『E2Eだけがテスト自動化じゃない！ Unity製ゲームの開発者テストチュートリアル』フォローアップ

CEDECはじめゲーム領域でもテスト自動化の事例紹介が増えましたが、従来の手動テストを自動テストに置き換えるアプローチが紹介されることが多く*1、ROIが高く小規模なタイトルであっても取り組める開発者テストの事例・情報は少ないのが現状です。

そんな中、CEDEC2025 で開発者テストについての招待講演のお話をいただき登壇してきました。タイムシフト視聴は 8/4 10:00 AMまでなので、パスをお持ちの方はぜひご視聴ください。

cedec.cesa.or.jp

スライドはこちら（CEDiLと同じもの）

参考リンク

スライド中にも埋め込んでありますが、リンクを書き出します。

Automated Testing of Gameplay Features in 'Sea of Thieves' (GDC2019)

バグ数のグラフだけ引用しましたが、開発者テストの導入だけで得られた結果ではなく、テストの運用も徹底した成果です。それも含め、参考になるはずです。

スライド

www.gdcvault.com

動画

www.youtube.com

Unity公式パッケージ

OSSパッケージ

参考書籍

ユニットテストと統合テストについて、ゲーム本体のテスタビリティとテストコードの保守性にフォーカスしてお話しました。またAnjinによるゲームプレイテストについても、ごく一部のユースケースしか紹介できませんでした。いずれも、詳しくは同人誌に書いておりますので参考にしてください。

セッションでも触れましたが、『Unity Test Framework完全攻略ガイド』は夏のコミックマーケット106で第3版に改版予定です。電子版は今BOOTHに出ているものをご購入いただければアップデートされます。技術書典マーケットも同様にアップデートしますが、タイミングは次のイベント開催時期（11月）になりますのでご注意ください。

ikagoya.booth.pm

ユニットテストのセクションで紹介した各種パターンの名称は、xUnit Test Patterns (xUTP) で紹介されているものです。やや古い書籍ですが、現在でも現役で使用しているパターン集です。

xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler)) (English Edition)

作者:Meszaros, Gerard
Addison-Wesley Professional

Amazon

Ask the Speaker

多数の方に来ていただき、ほぼ時間いっぱい色々お話させていただきました。覚えている範囲かつ書けるものだけ紹介します。

Test RunnerウィンドウのPlayerタブが使いにくい件

Unity Test Frameworkパッケージ（以下UTF）v1.3.xまでは、Play Modeテストを名前やカテゴリで絞り込んでから、エディタ内で実行ボタンかプレイヤー実行ボタンで実行できました。つまり、同条件での実行が簡単でした。

UTF v1.4からプレイヤー実行はPlayerタブで実行するようになったため、開発（変更）した箇所のPlay Modeテストをエディタ実行した後、同条件でプレイヤー実行するには、タブを切り替え、名前やカテゴリの絞り込みを再度行なう必要があり不便になりました。

同じ不満を持った方によるフォーラムの投稿 Test Framework 1.4 / 1.5 feedback and bugs (IN-88016) がありますので、同様の感想をお持ちの方はLikeするなどしてほしいです。

また、タブを分けるのであればテストの有効/無効に UnityPlatform属性を反映してほしい（現状はPlayerタブでもEditorと扱われる）という要望かIssueを投げてリジェクトされた記憶があるのですが探し出せませんでした*2。

開発者テストをどこから導入すべきか

テストが開発の役に立つという体験が先決だと思っています。2つアプローチがあります。

Anjinで広く荒くカバーするテスト（アウトゲームの画面遷移やチュートリアルなど）をCIで定期実行し、「QA向けビルドが壊れた」ときに早く検知できるようにする
実際の開発プロジェクトではなく、ユニットテスト習得のための題材*3でワークショップを実施する

ワークショップで実際のプロジェクトを使わないのは、テスタビリティが低いところがあったり担当箇所によって体験に差が出るためです。ワークショップ実施前に参加メンバーで『Unity Test Framework完全攻略ガイド』の読書会を実施するのもおすすめです。

統合テストにはどう取り組めばいいのか

統合テストのターゲット、粒度の設定などは、ゲームタイトルごとに異なります。ゲームジャンルによる差異だけでなく、そもそも工程の考え方もドキュメントの粒度も標準的なものがなくバラバラなので。

まず観点として「なにをテストするのか」（もしくは「どのようなバグを見つけたいのか」）から出発します。わかりやすいのは仕様書に書かれている粒度・精度（解像度）、機能実装のPull Requestに書いている確認内容をテストコードにするという考え方です。

たとえばアウトゲームであれば、UI操作を通して「〇〇画面に遷移して〇〇機能を実行すると何が起こるのか」といったテストが中心になるでしょう。インゲームの例として前掲の Sea of Thieves では「敵キャラが索敵、プレイヤーを発見、接近、攻撃」するという一連の振る舞いをActorのテスト*4として実施したことが紹介されています。

バグが出たときに「自動テストがあれば見つかっていた」と言う話はすべきか

大いにすべきだと思っています。目的は将来もしくは次のプロジェクトでの改善で、すぐには着手できなくともチームの課題意識を高め解像度を上げていく効果が見込めます。ただし漠然とした「テスト」という表現では意味がなく、具体的にどのような観点のテストであれば発見できたかまで言及しないと机上の空論となり無意味です。