Unityテスト完全に理解した
https://gyazo.com/aced68966ae53b32c2952339ef50e8af
青木とと
概要説明
@toru_inoue
「実機、自動、利のあるテストに食らいつく話」
Unityのゲームフレームワーク
Unityエディタ上でRun allってやれば各単体テストを実行できる
PlayModeと挙動が違うので失敗したりする
UnityでPlayModeでテストを実行する
自分で作った
Unityのシーン上で各単体テストを実行していくRunner
Unityで実機でテストすることもできる
自分で作った
課金のテストは課金ダイアログが表示されて、そこは人間が押す必要がある
テストの利益
テストが通っている限りその機能は健在
心が安らぐ
体力が減らない
人力でテストしてたら疲れるでしょ
PlayModeでのテストケース例
UnityTestクラスは単なるIEnumerator
Setup：シーンのロードを待つ
ゲームオブジェクトを探す
WaitUntilなどのメソッドで待ってから条件判定とかできる
Teadown：シーンをアンロードする
1秒で終わる程度の小さいテストを積み重ねて複雑なテストを実現するのがオススメ
Unityエディタの挙動は実際のターゲットプラットフォームでの挙動とかなり違う
最初からすべてのプラットフォームでテストを通そうと思うと死ぬ
とりあえずUnityエディタで通るようにテストを書く
そのままiOS/Androidでテストを動かすと大抵失敗するので、#ifで調整する
どのみち実機でしか動かない機能
通知
課金
プラグイン
Unityの最新機能を試すのにPlayModeのテストを使ったりしている
試行錯誤が楽
@monry
プロジェクトのコードをテストしやすくする手法について話をします
Unityテストにおける課題
疎結合の基本的な考え方
CAFUについて
テストとは
UnitTest：単体テスト
IntegrationTest：複数機能にまたがる結合テスト
SystemTest：E2Eテスト
Unityでテストを書くのがしんどい理由はたくさんある
状態のテスト
外部データが必要なテスト
...etc
ゲームの開発においては
クラスが他の複数のクラスと関係していたりする
あるクラスのインスタンスが複数必要だったりする
タップの入力イベントを前提にする部分のテストが難しい
密結合罰あるある
SingletonMonoBehaviour
static
...etc
疎結合の基本
疎結合なシステムならば、シンプルなテストで済む
クラスから少し視野を広げて、レイヤーに関する関心の分離をしよう
プレゼンテーション層
ドメイン層
データ層
プレゼンテーション層とドメイン層の分離は進んでいる：UniRxなど ドメイン層とデータ層の分離については、まだそこまで言及されていない事が多い
CAFU：Clean Architecture For Unity intefaceのみを提供
プレゼンテーション層
プレゼンター
ビューとユースケースをつなぐ
ビュー
プレゼンターにのみ依存
ドメイン層
ユースケース
ビジネスロジックの実装
リポジトリー
トランスレーター
モデル
データ層
データストア
データの取り扱い方法を実装しているレイヤー
エンティティ
データの構造を定義したレイヤー
@adarapata
「Unityプロダクトにテストを導入していくまで」
インゲームとアウトゲーム
ゲーム体験のコアの部分がインゲーム
繰り返し遊んでもらうための部分がアウトゲーム
どこにテストを導入するか？
インゲームの部分は最適化とかゴリゴリで大変
アウトゲームの部分のほうがテストしやすかった
アウトゲームのUnitTest/UITest
MVRPアーキテクチャ
Singletonが多め……
PureClassのテストを黙々と書く
まずは、新規に作るモデルのテストを書き始めた
実体に強く依存する
Mockに差し替えづらい
ゲームではSingleton生まれがち……
Singleton減らす方法
SingletonをZenjectに置き換えていく
inteface定義
テスト時に適当なデータを持ったMockを作れるようになる
SingletonInstallerをどこに置くのか問題
ProjectContextに持たせる
Zenjectの機能
常に呼ばれるようになるので注意が必要