トレーナー、メンターそしてコンサルタントでもあるMichael Feather氏は最近の投稿でユニット・テストそのものがコードの品質を向上させる(リンク)という広く普及した考え方について論じている。Michael氏はユニット・テスト、インテグレーション・テスト、TDDそしてクリーン・ルーム・ソフトウェア開発について言及し、コードの品質というのは思索と熟考から得られるのであってバグの抑制から得られるのではないと結論付けている。M3P社の独立コンサルタントSteve Freeman氏はMichael氏のアイディアを発展させ、"経験知に基づくTDDの最適化"(リンク)について語りTDDがなぜ役立つのかを説明している。
Michael氏はテストを通してバグを潰していくことで品質向上をはかるという考え方には欠点がある(リンク)と考えている。
ユニット・テストに関する最も一般的な説の一つはテストで見つけたエラーを取り除くことによって品質が保たれるというものです。一見これは正しいように思えます。テストは成功または失敗します。そして失敗した際に問題があることを知り、それを修正します。もしあなたがこの説に賛同しているのだとしたら、あなたはインテグレーション・テストで発見されるインテグレーション段階のエラー、ユニット・テストで発見される「ユニット」段階のエラーがより少なくなることを期待するでしょう。それは素晴らしい説です。でも間違っています。このことを確認するにはユニット・テストを他の品質向上の手段と比較するのが一番です。劇的な効果を得られる手段と（比較することです）。
持論を証明するためMichael氏はクリーン・ルーム・ソフトウェア開発について語っている。これは1980年代に使用された方法である。Michael氏によるとクリーン・ルームではユニット・テストは一切存在しないという。
クリーン・ルームという概念の背後には開発の厳格さを増すことで品質が向上できるという考え方があります。クリーン・ルームでは小さなコードの断片一つ一つについて述語論理＊を記述し、レビューの際に書いたコードが記述したその述語に過不足ないことをデモンストレーションしなければならなりません。とても厳格な方法です。そして実際には私が述べたより徹底的なのです。クリーン・ルームのもう一つの教義はユニット・テストが存在しないことです。まったく（存在しない）。ゼロです。コードを書いてそれがレビューされたらそのコードは正しいと仮定されるのです。唯一のテストはと言えば、機能レベルでの確率論的なテストになります。
興味深いのはクリーン・ルームが結果を残していたということだ。一切のユニット・テストを行わずに品質を向上させていたのだ。クリーン・ルームに起きたこととTDDに起こることはとてもよく似ている。開発者は継続的なレビュー、リファクタリングと品質向上を強制されるのだ。Michael氏は以下のように結論付けている。
要するにテストを機械論的に扱うことはできないということです。ユニット・テストでエラーを取り除くことでユニット・レベルの品質を向上させることはできないのです。同様に、インテグレーション・テストでエラーを取り除くことによってインテグレーション・レベルの品質を向上させることはできないのです。真実はもっと繊細なものです。品質は思索と熟考から得られるのです。正確な思索と熟考です。これが品質の魔法です。技術は常に品質を向上させるのを補強するのです。
Michael氏の投稿を発端にM3Pの独立コンサルタントであるSteve Freeman氏は、そのアイディアをさらに発展させて"経験知に基づくTDDの最適化"(リンク)について述べている。開発者は自分のコードにに影響を与える判断をすることがある。
実は人は慎重にトレード・オフを検討し最適な方法を選択するということにあまり時間を掛けていません。その代わりに"最初に合致した"方法を採用します。それまでの学習成果のリストからこれで十分だろうと思える最初のものを選択するのです。これらは全て無意識に行われています。そしてその後でニブイ脳みそが動き始め選択された方法を最適化するのです。このようなことが起きていることにさえ気付きません。
最初に思い浮かんだ方法を採用するのを止めて、多くの選択肢を評価することである。そしてSteve氏によればだからこそTDDが役立つのである。
テスト駆動開発は最初に合致したパターンを壊すことで機能する（あるいは機能すべき）のです。最初に思い付いた案にこだわるのを防ぎ、本当の問題となっていることを解決するのです。楽をしている状態から抜け出すことを強制し、本当の要求に注意を向けさせるのです。さらに良いことに、テストから始めることで私達はまずそれが必要な理由（何のためのテストなのか）を考えることになり、その後で私達の専門家的な思考が提供したがっている解決策について考えることになるのです。
Steve氏はこのことを証明するために例を挙げている。
Promiscuous Pairing(DOC)を実施したArlo Belshee氏のグループが一番の証拠になります。彼らは経験的に2，3時間程度でペアを交代しているときが最も生産性が上がることに気付いたのです。これは誰もが想像したことの正反対のことです。そのやり方によって常に「初心者の思考」の状態にいることができるという利点があるというのが彼らの見解です。
原文はこちらです：http://www.infoq.com/news/2008/06/Unit-Testing-Silver-Bullet