- 動画 https://www.youtube.com/watch?v=Q-FJ3XmFlT8&feature=youtu.be&t=1121
- 講演開始は 0:18:40 から
今回の狙い
- TDDは言葉はよく知られているが、実際にやっている人は多くない
- そのためイメージ先行の誤解が多い
- 実際に見てもらうことで正しく理解してほしい
- 0:23:30 テスト駆動とは何か
- 0:28:00 「動作するきれいなコード」をいきなり書くことはできない
- だから「動作する」と「きれいな」を分割する
- 設計しないのではなく、「設計し続ける」が正しい理解
- 0:32:00 どこから手を付けるか？「重要度」 or 「テストしやすさ」
- 0:44:00 FizzBuzzを題材に
- なんどもサイクルを回したいので、十分に小さい問題を取り上げる
- 0:45:00 ～ 0:56:00 最初に「あいまいな仕様」を「実装可能なTODOリストに分解」する
- ※詳細設計の具体例として、この部分だけでも必見
- 0:57:00 テストコードの記述を開始
- ※Eclipse + JUnit なので、エンタープライズ系での開発でも参考になりそう
- 1:05:00 環境を確認後、実際のテストコードを書き始める
- 最初は全体の設計から行うので、テスト項目は簡単なものを選ぶ
- 1:18:00 最初のテストが予想通り失敗することを確認→モードチェンジして実装に移る
- 仮実装、テスト通過、テスト追加（三角測量）、本実装
- 1:30:00 リファクタリング（プロダクトコード→テストコード）
- 1:44:00 テストコードの重複を取り除くリファクタリング
- 1:52:00 歩幅を調整しながら、実装を継続
- Q&A (1) 1:37:00
- Q: こうしたタスクの整理・分割のスキルを身につけるのに良い練習方法などあれば知りたい
- A: テストのしやすさが理解できてないと、難しい。最初はできなくてよい。やっていくと分かってくる。設計を学んでいくと、テスト容易性が高いところと低いところが分かってくる。書籍ならクリーンアーキテクチャーでは、入出力から遠いことがテスト容易性が高いと書かれている。例えばプリントしていると容易性が低い。経験と本からの理論の両方が必要。
- Q&A (2) 1:39:00
- Q: 複数組み合わさった内容をテストしたいときはそういうテスト用のメソッドを作るべきですか？そもそも分解が間違っている？
- A: 一緒にテストしないと意味がない場合は一緒に。でも最初は分離できるのではと疑ってほしい。インテグレーションテストやE2Eテストのように実行に時間がかかる場合は、複数アサーションもあり。
- Q&A (3) 1:55:00
- Q: 外部仕様/ストーリー/ユースケースをインプットとしてTDDで開発するときはE2Eテストをまず書くのが良いか？xUnitが使えない時にテストファーストで書けなくて悩んでいる
- A: E2Eテスト、受入テストを書いてから、内部に進むのがおススメ。粒度の違う複数のテストを組み合わせる。書籍「実践テスト駆動開発」が参考になる
- 1:57:00 途中でリリースして3年後に起きること、こうしたかったという感想戦
- テストコードの構造化で、仕様を表現する
- 2:11:00 テストコードのリファクタリングで、負債化を防ぐ
- 問題を小さく分解する
- 歩幅の調整
- テスト → 仮実装 → 三角測量 → 実装
- テスト → 仮実装 → 実装
- テスト → 明白な実装
- テストの構造化とリファクタリング
- そうしないと、歩幅の異なるバラバラなテストが残ってしまう
- あとで見ても仕様が分からなくなる