TDD適当講座

仕事中のお話しです。

周りの声から、
ソースコードが単体テストを行うのに不向きとなっているという言葉が聞こえました。

ただの推測でしかありませんが、
ここでいう単体テストはJUnitのようなライブラリを使ったテストだと思われます。

なるほど、
確かに意識して書かないとテスト可能な実装になんてまずなりません。

ならないからこそテストを先に書く必要性があり、
TDDが生きてくるわけです。

でもまぁ、
先にテストを書けを言われて簡単に書ける人はそうは居ないでしょう。

なのでテストを多少後回しにしても大丈夫な指針でも出してみます。

別に難しいお話しではありません。

JavaならCheckStyleを使って良いスコアを叩き出せば良いだけです。

クラス・メソッドの行数、
引数の数、
入れ子の深さ、
サイクロマチック数、
結合度、
このあたりに閾値を設定しておいて、
警告が出ないようなコーディングを行えばかなり良くなります。

問題があるとすれば、
下手な人はいつまで経っても警告を消せないということです。

テストを前提としたコーディングでは、
今までごまかしてきたコーディングのレベル差が出やすいのです。

それも早い・遅いではなく、
できる・できないレベルに達するほどです。

自分はTDDが必ずしも必要だとは思いませんが、
こういったふるい分けができるという点では大好きです。

まあ管理的には顔面蒼白ものかもしれませんが…

もしも自分のチームでTDDを導入するのであれば、
・元から全員レベルが高い
・TDDを教えるプロフェッショナルが居る
・出来ない人を切り捨てて構わない
のいずれかを満たしてないと辛いのではないでしょうか。



結局何が言いたいかというと、
不相応なレベルで導入しようとすると痛い目をみますよってことです。

レベルが不足しているのであれば、
テストが不能なソースコードが生成されることを甘受するしかありません。

とりあえずTDDは考えず、
CheckStyleを守れるか守れないかで測定してみては？
※JavaではないならSourceMonitorとかでどうぞ。