レバレッジメモ: レガシーコード改善ガイド
レガシーコード := テストがないコード
テストを作成するためには対象とするクラスから他のクラスへの影響を把握する必要がある。依存関係を排除しておけばニセのクラスを突っ込んで影響を直接観察できる。
テストをするたびに本番コードを編集するわけには行かない、なのでコードを編集せずにテストに不都合な挙動を変えられる場所が必要である。これをseamという。どのseamも、その挙動を変更するenabling pointを持っている。
日本語で「接合部」っていうとくっつけることに意識が向きがちだけど「そこで切り離せる」というほうが重要なのだな。
既存のレガシーコードに機能追加をする方法
1: スプラウトメソッド
テストされてない既存のコードに書き足すのではなく、新しいメソッドを作ってそれを呼び出すようにし、その新しいメソッドにテストを書く
2: ラップメソッド
テストされていない既存のメソッドの前か後ろに処理を付け足す場合、テストされていないメソッドの名前を変えて、元の名前で古いメソッドと新しく追加する機能の入ったメソッドを呼び出すようにし、その新しいメソッドをテストする。
TDD
Liscovの置換原則
サブクラスYのオブジェクトはいつでもスーパークラスXのオブジェクトとして使えなければならない。さもないとユーザがあるX型の変数に入っているオブジェクトが実際にはY型であることを意識しなければいけないようになってしまう。
Nullを渡す
Javaのような実行時のnullに対するアクセスを察知できる言語なら、テスト用に作るのが面倒なオブジェクトが必要なときに単にnullを渡せばいい。必要なものは必要になったときに例外で教えてくれる。
影響の調査の仕方
影響スケッチを描く
変数と戻り値が変わる可能性のあるメソッドをまるで囲む。影響を矢印で書く。
よく設計されていればこれはシンプルになるはず。