「レガシーコード改善ガイド」という書籍を読みました。考え方から具体的な手法まで説明されていて良い本でした。特に気になった部分について、自分の解釈した内容をメモしておきたいと思います。
書籍概要
レガシーコード改善ガイド (Object Oriented SELECTION)
作者: マイケル・C・フェザーズ
発売日： 2009/7/14
考え方
なぜテストが必要か？
まずは、始めの数ページ目に書かれていた次の言葉にハッとさせられました。
テストのないコードは悪いコードである。どれだけうまく書かれているかは関係ない。どれだけ美しいか、オブジェクト指向か、きちんとカプセル化されているかは関係ない。テストがあれば、検証しながらコードの動きを素早く変更することができる。テストがなければ、コードが良くなっているのか悪くなっているのかが本当にはわからない。
テストの粒度としては、メソッドレベルの単体テストを想定。実行時間が短く、エラー個所の特定がしやすく、コードが確実に動作したことを確認（カバレッジ）できることが重要。
作業時間
テストケースのコーディングは、単純に作業量が増える。
これは、次回のイテレーション時に対する投資であり、次のイテレーションが発生したタイミングで、回収できる。次回がなければ、回収できないですね。
あと、書かれていませんでしたが、開発チーム/環境によっては、次回イテレーションまで、テストコードを保持し続けるのが、手間だったりする気がします。
手動でテストするほうが早いこともしばしばある。ただし、コードを変更するたびに再テストすることを考えると、トータルの作業コストは考える余地がある。
テストの仕掛け
テスト対象のコードに対して、次のような仕組みが必要となる。
- 検出：テスト結果にアクセスできること。
- 分離：テスト対象を、テスト対象外の処理から切り離して、動作させることが可能であること。
検出と分離をするために、テスト用に動作を切り替えられる場所を「接合部」と呼び、次の種類がある。
- プリプロセッサ接合部：CやC++言語のようなプリプロセッサ機能を使う方法（頻度「少」）
- リンク接合部：CやC++言語ではリンカ、JavaではCLASSPATHで切り替える方法（頻度「少」）
- オブジェクト接合部：クラス/インターフェース継承、メソッドのオーバーライド/オーバーロードを活用する方法（頻度「大」）
テストコード作成を支援してくれるツール
- 自動リファクタリングツール：Eclipseにもいろいろなリファクタリング機能がありますね。
- モックオブジェクト：Mockito／EasyMock／jMockなどありますね。
- 単体テストハーネス：JUnit／NUnitなどありますね。
- カバレッジツール：書籍ではカバレッジ確認用のツールについて話がなかったのですが、、、。
今日はここまでとします。
次回は、実際のテストコードについて、まとめたいと思います。