内容はあくまで私の主観です。いつも通りコメントは大歓迎ですが、長文であれば別途投稿してもらえたほうが有益だと思います。
自分のスタンス
- 自動テストは素晴らしい。どんどん利用していくべき。
- テスト駆動開発の主張に同意できない。
TDDの何がしっくりこないか
TDDの主張がしっくりこない
TDDの肝は「テストを先に書くことで思考をクリアにし、実装を早くする」「Red-Green-Refactoringの繰り返し（以下、TDDのサイクル）というガイドを用意することで開発者を安心させる」だと思っている。
まず一つめが納得いかない。世の中のプログラマは本当にテストが無いと行き当たりばったりで全く保守できないような実装をしてしまうのだろうか。少なくとも私はテストの有無に依らずそれなりの設計をする自信がある。
最初にテストがあれば「テストしやすいコードを強制させる」ことができるのはまあ正しいだろう。しかしテストを書くことが念頭にあれば実装コードは自然とそうなるし、むしろテストを書く時点で実装側の良い設計を想像するほうがよほど難しい。
次に、「テストしにくいコードがある」にもかかわらず、TDDのサイクルを強制するのが気に食わない。
あなたの作ったプロダクトを顧客に見せたら「この部分に会社のロゴを入れてくれ」と言われた。あなたはこれに対してどのようなテストを書くのだろうか。
おそらくあなたはテストを書かない。「これはリソースの変更だから」「ロジックに変更は無いから」などと言い訳する。あなた変更後アプリを実行し、確かにロゴが表示されていると確認する。これは自動テストを書く代わりに手動テストを行ったことに他ならない。ロゴが表示されていることをテストすることは可能だ。「そんな修正にテストを書くのは割に合わない」という本音を「リソース修正だから」などという建前で覆い隠しているだけだ。
どのような修正でもテストは必要だ。しかし自動テストがコストに見合うかは場合による。全ての修正に対しテストを書くことは現実的ではない。
TDDを行ったとは何なのか。「私のコードは行数にして80%をTDDしました」とでもいうつもりなのか。
周りのTDDerのやってることがしっくりこない
DHHもそうだが、「遅いテスト」を書いてTDDを名乗るのはやめてほしい。遅いテストによるTDDは「コミットのたびに上長の許可が必要なSubversionを使う」のと同等だ。
TDDのテストは開発者を安心させるための支えだ。本当であれば1行変更するたびにでもテストを実行して「自分の行動が間違っていない」ことを振り返りたいのだ。しかしテストが遅いと常に安心していたいのが、5分に一度の安心になり、1時間に一度、1日に一度と安心できるタイミングがどんどん減っていく。
「コミットのたびに上長の許可が必要なSubversion」はどう運用されるか。私であればリリースビルドのときだけまとめてSVNにコミットするようにするだろう。自動テストが遅いからこそJenkinsなどで夜間にテストを回すのだ。開発者は次の朝まで安心できない。
さいごに
TDDに関して話していると、どうにも「自動テストの良さ」でありTDDでなくても恩恵を得られるものを褒め称えている人が多いように感じる。
本当にテスト駆動開発はよいものなのだろうか。