ユニットテストが通ったコードに対する安心感は、結構ある。実際にバグもだいぶ予防できている気がする。
ただ、人は面倒くさがりなもので、「テストコードをたくさん書いたら、メンテ対象のコード量がその分増える。めんどい。」みたいな気持ちが起こってきて、当初のTDDへの意気込みが薄れてくる。
面倒くさいという感情一つで、100の理屈も吹っ飛んで、当初の夢のプランが脆くも崩れ去る。我々はそんな残酷な世界を生きている。
ただ、そんな世界でも生きねばならないので、ちょっとでも対抗したい。そのために、次の2つのシンプルなルールを適用してみてはどうかと考えた。
- 自分のコードがちゃんと動くかどうか不安を感じたら・・・
- テストできるようにリファクタリングして、
- テストケースを書け。
- クロスレビューを必ずやって、そのとき他人のコードがちゃんと動くか不安を感じたときには・・・
- コードの行数範囲を明示した上で、「テストできるようにリファクタリングして、テストケースを書け。」ととりあえずコメントしろ。
プロジェクトリーダーは、ユニットテストをやるためのツールセットを用意し、何度か繰り返してクロスレビューをやる計画を立てておく。クロスレビューでは、上記のルールを設定して実施する。
まだちょっとしか実践していないから、ルールの過不足は不明。
下記のようなものになんとか対抗したいというのが意図。
- 他人の指摘がないと、リファクタリングやテストケース書きなどやる気がおこらない。大抵の人は、自分に甘く他人に厳しい。
- カバレッジとかの簡単すぎる基準を設けて無理にやらせると、本質を捉えてちゃんとやってる人まで罰することになる可能性がある。これはやる気を絶望的に低下させる。
- 必要と感じられないようなテストコードをメンテし続けるのは苦痛。
- ちゃんと動くか不安になるようなコードは、大抵関係ないコードとごちゃ混ぜになって長いコードになっている。そういうバグの温床をピンポイントで攻撃すれば、費用対効果は高い。
TDDのいいところは、コードに対して網羅的にやらなくても効果があること。部分的にやったとしても、やった分だけバグの可能性が減る。
必要だと自分で思ったところだけをやるんだったら、面倒くさいという感情にも対抗しやすいのではないかというのがミソ。（特に面倒だと思わないのなら、それはすごい！そういう人は全部ちゃんとやってもらってOK、大丈夫。）
sed -e 's/面倒くさい/コスト/g' < this.md
Test Driven Bugfix...