cleancodersのStack Kataを見て感じたことのまとめ
前回、cleancodersのStack Kataのビデオに個人的な解説を付けました。
しかし35分のビデオに詳細な解説を付けたので長文になってしまい要点が読み取れません。
そこでこの記事では要点のみをまとめます。
私の個人的な理解なので合っているとは限りません。正解が知りたい人はcleancoders.comのAdvanced TDDというシリーズで勉強してください。動画は有料です。
Redですること
- 原則としてもっとも原始的（degenerate）で周辺的（peripheral）な試験から行う。
- この原則からどのように実践に落とし込むかについては説明が理解できておらず、現時点では自分の中で２つの仮説がある。
仮説１：Stack Kataの手順から推測
・最初の試験の選び方
- 空のオブジェクトで試験できることから試験する。
- 核心機能の周辺的な確認に必要な機能から試験する。
- 周辺機能の最も原始的なパターンから試験する。
・その後の試験の選び方
- 核心機能の試験に必要な周辺機能の試験
- この中で核心機能の周辺的な部分が実装されることがある
- 核心機能
- 核心機能がないと試験できない周辺機能
・各試験は空→単数→複数→エラーの順で実施する
- 空ケースでエラーが発生する場合は単数ケースから始める
- 単数ケースで複数ケースに対応できるコードができた場合、複数ケースの試験はスキップする
仮説２：Stack Kataのコメントから推測
以下の順に実施する
- 空オブジェクトで試験できること
- 核心機能の周辺部分
- 核心機能の核心部分
- 核心機能を利用する周辺機能
Greenですること
Compile Error発生時
- Compile Errorが出ていればCompile Errorを消すための最小限の実装を行う。
- 具体的には空のクラス、空のメソッド、空のフィールドなどを作成する。
- メソッドのSignatureを変えることもある。
- なにかreturnする必要があるときはAssertion Errorが出るものを返す。（null, -1など）
- 目標はCompile Errorが消えてAssertion Errorが出ること。
Assertion Error発生時
- Assertion Errorが出ている場合はAssertion Errorを消すための最小限の実装を行う。
- このとき最も汎用的でない方法（以下参照）で解決することを目指す。
1. まずは空で実装。
2. 次は単数で実装。
- マジックナンバー
- 計算
- 変数
- 分岐
3. 次は複数に対応する。
- 配列
- Collection
- while
- recursive
- for
4. なるべく避けたい手を使う
- 代入
- if/else文、switch文
5. きれいにする
- 重複除去
Blueですること
- 重複があれば取り除く。
- assertの中がごちゃごちゃしていればすっきりさせる。
- Testもコードであることを意識する。
その他
- 試験と実装を繰り返す中でコードは汎用的になり、テストコードは具象的になる。
