印象に残った内容

テスト駆動開発の2つのルール
- テスト失敗した時のみ、新しいテストかかる
- 重複を除去する
「レッド・グリーン・リファクタリング」は TDD の合言葉
TDD のゴール
- きちんと動く綺麗なコード
  - 要件満たしている
  - バグがない
  - 可読性、保守性が高い
TDD は開発スタイルであって教義ではない
- デメリットを考慮して使うべき
TDD は万能ではない
- 他のテスト戦略手法と合わせて使う
テストはパラメータ化しておくこと
- 不安な条件が発生しても気軽に追加・テスト可能になる
テストの過剰設計かどうかの判断
- RED → GREEN にする段階で1時間とかかかるのは過剰気味
- 20 ~ 30 分テストから離れるのは不足気味
パラメータ化テストはテスト対象の性質とテストコードの可読性を考慮して期待値毎に分ける
- FizzBuss で言えば、全部1つのコードにまとめるのは極端かも？
- 数字の時、Fizz の時、Buss の時で分けると可読性が高い
「アサーションルーレット」というアンチパターン
TDD と自動テストは違う
- TDD はテストコードを先に書く進め方で開発を進める開発手法
- 自動テストは TDD に含まれる概念
自動テストの目的
- 機能の増加に伴う、回帰テストの実行コスト増加を抑えるため
  - テストが物理的に出来なくなり、バグが発生しやすくなる
  - リファクタリングも難しくなる
- 正しい挙動の定義が分からなくなることをなくすため
  - テストコードに想定される挙動が記述されるため
TDD が解決したい課題
- 十分なテストが書かれやすい
  - プロダクトコードとテストコードがセットで書かれるため
  - 後からテストを書くと必要なパターンが漏れやすい
TDD のおすすめの進め方
- RED → GREEN まではとりあえず動くものをいち早く作る
- 細かい設計は REFACTORING でおこなう
- テストしにくいなと思ったら別メソッドに切り出す
カバレッジ高い = テストが十分ではない
- アサーション 0 でもカバレッジ 100 % にはなる
- ただし、足りないことはわかる

所感

TDD は特別何か勉強したりしたことはなかったので、TDD の目指すところや注意点が改めてきちんと理解出来てよかったです。

私は業務でもプライベートでもコードを書くときは DDD を意識して書くようにしていますが、本勉強会を聴講して DDD と TDD の親和性は高そうだなと感じました。

なので、これを気に今後は TDD のメソッドも取り入れながらどうやったら短期間でバグの少ないコードをリリース出来るかについて考えて行きたいなと思います。