yr-learning Vol50に参加してきた

https://yr-camp.connpass.com/event/341308/

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと想います。

前回に引き続き、Trading Card Gameのモブプロをしました。議論したポイントを以下に書いていきます。

どういう順でテストを書くか？(TODOをどう作るか？)

• (先攻が)ゲームに必ず勝利する
• ライフを0にしたプレイヤーがゲームに勝利する
• ターンを変えるとアクティブプレイヤーが変わる

という順で実装しようというのを計画段階では考えました。ライフサイクルが長いテストケースから作ってみるというのが理由です。

ただ、実際にやってみると、2つ目のテストと1つ目のテストのAssertが変わらないので、2つ目のテストを書くとredにならない(正確にいえばコンパイルエラーさえ直せばGreenになってしまう)という問題があり、それなら2つ目と3つ目を変えてみればいいんじゃないか？という話になりました。
しかし、いざ変えてみると、1つ目から3つ目への変化は歩幅が大きすぎて、ActivePlayerを取得するふるまいとターンを変えるふるまいの2つを実装しないといけなくなってしまうことに気が付き、結局元のプランのほうがいいし、なんなら歩幅をもっと小さくして、ライフが0になったPlayerに応じて勝者が切り替わるテストを追加したほうがいいんじゃないか？という話になりました。

Game.ActivePlayer()は必要か？

テストをする際にGame.ActivePlayer()をめちゃくちゃ生やしたくなるのですが、このGameの仕様的にGameのアクティブプレイヤーが知りたくなることはまずない(強いて言うならActivePlayerは〇〇さんです、と表示されるようなパターン)と思われるので、このメソッドを生やすのはアンチパターンなんじゃないか？という話をしました。

Game.activePlayerは許されるか？

フィールドを直接参照する形にすればさっさとターン交代のテストが書けるのでそれはどうか？という話が出たのですが、これはフィールドを直にさらしていることになるので許されないと思うという話になりました。

ドライバー交代はTDDのサイクルでいうといつ？

自分をはじめ3人中2人はリファクタリングが終わったタイミングでドライバー交代するのがいいんじゃないか？という話をしたのですが、TDDyy会ではレッドになったタイミングでドライバー交代するという話が出ていて、今回はそれでやってみようという話になりました。(テストを書いた人のイメージに引っ張られないで実装が作られそうなのでテスト自体の吟味が起きる可能性がある)