ジョエルのテストにテスト駆動開発が欠けているのはなぜですか？

Joel Spolskyが書いたこのブログを読んで、コードを改善するための12の手順を説明しました。テスト駆動開発の欠如は本当に驚きました。だから私はグルに質問を投げたい。TDDは本当に努力する価値はありませんか？

テスト駆動開発は、 Joelがその投稿を書いてから 2年後の 2002年にKent Beckの本が出版されるまで、事実上不明でした。問題は、なぜジョエルがテストを更新しなかったのか、それともTDDが2000年によく知られていたら、それを彼の基準に含めたのでしょうか？

重要なことは、プロセスの具体的な詳細ではなく、明確に定義されたプロセスを持っているという単純な理由から、彼はそうではないと考えています。これは、特定のバージョン管理システムを指定せずにバージョン管理を推奨する、または特定のブランドを推奨せずにバグデータベースを作成することを推奨するのと同じ理由です。優れたチームは継続的に改善と適応を行い、その特定の時点での特定の状況に適したツールとプロセスを使用します。一部のチームにとって、それは間違いなくTDDを意味します。他のチームにとってはそれほどではありません。TDDを採用する場合は、それが貨物カルトの考え方から外れていないことを確認してください。

ジョエルは実際にいくつかの場所でこれに具体的に取り組んできました。

彼は、物事のテストでは多くの重要な問題、特に「このソフトウェアのユーザーインターフェイスはダメですか？」などの主観的な問題をキャッチできないと説明しました。彼によると、Microsoftでの自動化されたテストへの過度の依存が、Windows Vistaの結果となった方法です。

彼は、経験上、ユーザーが実際に発見するバグの種類は、2つのカテゴリーに分類される傾向があることを書きました。1）一般的な使用法で現れるバグ。 、または2）エッジケースが不明瞭であるため、そもそもそれらをカバーするテストを作成しようとは誰も考えなかったでしょう。彼は、彼と彼のチームがFogBugzで修正したバグのごく一部のみが、ユニットテストで検出された種類のものであると述べています。（私は今その記事を見つけることができませんが、誰かが私の言っていることを知っているなら、ここへのリンクを編集してください。）

そして、特にプロジェクトが多くの単体テストを含む非常に大きなプロジェクトに成長し、その後、（意図的に）何かを変更し、非常に多くの壊れた単体テストで終わる場合、それは価値があるよりももっと厄介になることができる方法を書いています。 彼は、ユニットテストが引き起こす可能性のある問題を、人々がジョエルテストに13番目のポイントとして追加しなかった理由として、具体的に使用しています。

Joel Spolsky自身が2009年にこの質問に回答しました。

ジョエル：テスト駆動開発については議論があります...あらゆる種類のユニットテストがありますか？そのようなもの...ジョエルテストを読んだ後、多くの人が私に書いてくれます。ここにあるもの：単体テスト、すべてのコードの100％単体テスト。」

そして、それは私があなたが必要としないかもしれない何かについてほんの少し教義的すぎると私を打つ。同様に、アジャイルプログラミングの全体的なアイデアは、必要になる前に何かをするのではなく、必要に応じてページフォールトすることです。すべての自動テストは、多くの場合、役に立たないようです。言い換えれば、実際に機能するコードを保証するために、非常に多くの単体テストを作成し、それが機能しないかどうかを確実に確認します。テストを書いてください]、実際にはまだ動作します...わかりません、私はそれをうまく表現していないので、このためにそのようなフレームメールを取得するつもりです。しかし、チームがユニットテストのコードカバレッジを100％本当に持っていた場合、いくつかの問題があると思います。1、彼らはユニットテストを書くのに非常に多くの時間を費やしていたでしょうし、品質を向上させてその時間を支払うことができるとは限りません。つまり、彼らは品質がいくらか向上し、何も壊さないという自信を持ってコードを変更できるようになりましたが、それだけです。

しかし、私が発見した単体テストの本当の問題は、コードの進化に伴って行う傾向のある変更の種類が、単体テストの一定の割合を破壊する傾向があることです。コードを変更して、ユニットテストの10％を壊すこともあります。意図的に。何かのデザインを変更したため...メニューを移動し、そのメニューに依存していたすべてのものが...今、メニューは他の場所にあります。そのため、これらのテストはすべて壊れています。そして、コードの新しい現実を反映するために、それらのテストに行き、それらのテストを再作成できなければなりません。

最終結果は、プロジェクトがますます大きくなるにつれて、本当に多くの単体テストがある場合、それらの単体テストを維持し、最新の状態に保ち、維持するために必要な投資額です。彼らは通り過ぎ、あなたが彼らから得る利益の量に不釣り合いになり始める。

ジョエル以外の誰も確実にそれに答えることができませんでした。しかし、いくつかの理由/観察を試すことができます。

まず第一に、テストはジョエルのテストに欠席していません

• テストは12ステップで直接2回言及されます（10および12）
• ビルドの存在は、最初のポイントの1つです。ビルドするという考えは、それらが壊れているかどうかを確認する能力を得ることです。そこで、ここでテストについても話します。

第二に、Joel Testの全体的なアイデア（私が理解しているように）は、素早く、はい、いいえの質問をすることです。「TDDをしますか？」正確には適合しません（答えは「私たちの一部」、「コードのその部分」、または「ユニットテストを行う」です）。

第三に、「時間の価値がある唯一のもの」（ところで、「あなたはプログラムしますか？」が載っていない）という点は、（ジョエルでさえ）誰も言っていないと思います。将来のチームメンバーとして、または顧客としても、ソフトウェアチームと連絡を取ります。これは、自分のIT部門がどれだけ良いか悪いかについての手がかりを探していた、私の周りの技術者以外の人に与えたリストです。それはすべてではありませんが、3分で倒すのは本当に悪いです。