Roppongi.unity #01のLT資料です。SpeakerDeckにアップロードできなかったのでSlideShareに上げています。最新のスライドは以下からhttps://speakerdeck.com/adarapata

What's hot

Humble Object Patternな話

• 1.
  Humble Object Patternな話Roppongi.unity#1 2019/02/21Roppongi.unity #1 2019/02/21
• 2.
  いもですいも(@adarapata)ゲームクライアントエンジニアadarapata.comRoppongi.unity #1 2019/02/21
• 3.
  ご注意2019/1/23にGotanda.unity #10で発表した「どこから始めるUnityTest」の時間切れで話せなかった後半部分にフォーカスした内容です。https://speakerdeck.com/adarapata/dokokarashi-meruunity-testなので前回と若干被る話が多いのでご了承ください。Roppongi.unity #12019/02/21
• 4.
  今日の話Humble Object PatternについてRoppongi.unity #1 2019/02/21
• 5.
  前提みんなテストが書きたくて手が震えているRoppongi.unity #1 2019/02/21
• 6.
  テストしにくさの元密結合staticなインスタンス入力イベントが絡む処理UIが絡む処理ファイル、DBなどの外部リソースが絡む処理etc..実際問題、どう綺麗に書いてもテストしにくい部分は出てくるRoppongi.unity #1 2019/02/21
• 7.
  テストピラミッド。上位に行くほど難易度が高いRoppongi.unity #1 2019/02/21
• 8.
  コスト高いのでテスト避けたいわかる時にはそういう判断も必要かもしれない書かない≠ 書けない書けない理由は明らかにすべき。ピラミッドの境界を跨ぐような処理を分割していくRoppongi.unity #12019/02/21
• 9.
  Humble Object Patternとはテストしやすいものとしにくいものを住み分ける実装パターンテストしにくいものの実装をHumble(控え目)にする多分初出はxUnit Patternshttp://xunitpatterns.com/Humble Object.htmlクリーンアーキテクチャ本にも載ってたので有名かもRoppongi.unity #1 2019/02/21
• 10.
  public class PlayerUnit: MonoBehaviour {[SerializeField]private float _speed = 1F;void Update(){var horizontal = Input.GetAxis("Horizontal");var vertical = Input.GetAxis("Vertical");Move(new Vector3(horizontal, vertical));}private void Move(Vector3 direction){transform.position += direction * _speed;}}きちんと任意の方向に動くかテストを実装したいRoppongi.unity #1 2019/02/21
• 11.
  書きにくさポイント入力が絡むので書きにくいMonoBehaviorの機能に依存しているので書きにくいSerializeFieldも同様でも移動する部分は書きたい書きやすいものと書きにくいものを切り分ける。Unityにおける書きにくいものは大体MonoBehaviour絡みなのでそこから切り出す。Roppongi.unity #1 2019/02/21
• 12.
  public interface IPlayerUnit{float Speed { get; }Vector3 Position { get; set; }}// MonoBehavior成分を０にしたけど、移動ロジックを持つクラスpublic class PlayerUnitController {private readonly IPlayerUnit _unit;public PlayerUnitController(IPlayerUnit unit){_unit = unit;}public void Move(Vector3 direction){_unit.Position += direction * _unit.Speed;}}テストを書きにくいMonobehaviorからロジックを抽出するRoppongi.unity #1 2019/02/21
• 13.
  public class PlayerUnitHumble: MonoBehaviour, IPlayerUnit {[SerializeField]private float _speed = 1F;private PlayerUnitController _controller;public float Speed => _speed;public Vector3 Position {get => transform.position;set => transform.position = value;}void Start() => _controller = new PlayerUnitController(this);void Update() {var horizontal = Input.GetAxis("Horizontal");var vertical = Input.GetAxis("Vertical");_controller.Move(new Vector3(horizontal, vertical));}}Roppongi.unity #1 2019/02/21
• 14.
  変更点移動処理の詳細と、Monobehaviorが離れた具体的な処理は PlayerUnitController に任せるようになったテストしやすいものとしにくいものに分かれたピラミッドの境界が明確になった切り分けられたので、移動処理のテストも書ける。入力のテストはやらない！移動処理を行う側はインタフェースだけ見ているので、差し替えが楽。Roppongi.unity#1 2019/02/21
• 15.
  IPlayerUnitは状況に応じて差し替えられるRoppongi.unity #1 2019/02/21
• 16.
  IPlayerUnitは状況に応じて差し替えられるRoppongi.unity #1 2019/02/21
• 17.
  テストコードpublic class PlayerUnitTest{// テスト用のいい感じモックpublic class MockPlayerUnit : IPlayerUnit {public float Speed { get; set; }public Vector3 Position { get; set; }}[Test]public void PlayerUnitMove() {var unit = new MockPlayerUnit { Speed = 5, Position = Vector3.zero };var controller = new PlayerUnitController(unit);controller.Move(Vector3.up);Assert.AreEqual(new Vector3(0,5F,0), unit.Position);}}Roppongi.unity #1 2019/02/21
• 18.
  まとめテストしにくい部分は発生するテストしにくいところとしやすいところを分けて、書ける領域を増やすHumble Objectはそれらを切り分けるRoppongi.unity #12019/02/21