ネタ元は、
私もテスト駆動自体は好きじゃないです。なんせつまんないです。でもユニットテストクラス自体は必要だなとは感じでいます。大規模開発になればなるほど、モジュール間の依存関係が読みにくくなります。仕様書から追っかけてもよいのですが、
- コードを直す
- テストコードを走らせる
- 依存先のテストが通らない
- 依存先の修正を行う
というような作業のスパイラルがユニットテストクラスによって簡潔にはなります。自分が理想としている形としては、
- コードを書く
- きっちりとしたJavadocを書く
- Javadocを元にテストコードを書く
という作業手順が理想的です。ちなみにテストコードを書くにはコードを書くのとは別の人です。テストコードを書く人がJavadocを元にテストコードが書けない場合、
- 設計が悪い
- Javadocがキチンと書かれていない
のどちらかになるでしょう。テストコードが書けるようなJavadocを書くことによって、コード＋コメントがそのまま品質の高い成果物となる。それが理想形ですね。ぶっちゃけそれも難しかったりするんですが。
コードレビューの話もでていますが、コードレビューは極力行わずに前のエントリでも書きましたが、ツールによって、
- コードメトリクスの計測
- コーディング規約のチェック
- バグパターンの検出
をコーディング中に行われるようにしています。IDEのプラグインにこれらの機能が存在するわけですが、それらの警告機能によって検出される警告を０にするようにコーディングすることで、コードレビューは省けると考えています。警告を０にするのが目的になったり、ツールを騙すようなコーディングが行われるようになれば、さすがに途中でレビューします。
なんかぐだぐだになってしまいましたが、自分としてはテスト駆動はいらないけど、テストコードは必要かなって感じです。