Joelのテストにテスト駆動開発が欠けているのはなぜですか？
Joel Spolskyがこのブログを読んでいました コードを改善するための12の手順 。 テスト駆動開発がないことは本当に私を驚かせました。だから私は達人に質問を投げかけたいです。 TDDは本当に努力する価値がないのですか？
ケントベックの 本 が2002年に発表されるまで、テスト駆動開発は事実上知られていない、2年afterジョエルがその投稿を書いた。質問は、なぜジョエルが彼のテストを更新しなかったのか、または2000年にTDDがよりよく知られていたら、彼はそれを彼の基準に含めたのでしょうか？
重要なのは、明確に定義されたプロセスであり、そのプロセスの具体的な詳細ではないという単純な理由で、彼にはないだろうと私は信じています。これは、特定のバージョン管理システムを指定せずにバージョン管理を推奨するのと同じ理由、または特定のブランドを推奨せずにバグデータベースを持つことをお勧めします。優れたチームは、その特定の時点での特定の状況に適したツールとプロセスを継続的に改善および適応し、使用します。一部のチームにとって、それは間違いなくTDDを意味します。他のチームにとっては、それほどではありません。 TDDを採用する場合は、それが cargo cult の考え方から外れていないことを確認してください。
ジョエルは実際にこれをいくつかの場所で具体的に取り上げています。
彼は、物事のテストは多くの重要な問題、特に「このソフトウェアのユーザーインターフェースは機能しないのか」などの主観的な問題を捉えることができないと説明しました。彼によると、 Microsoftでの自動テストへの過度の依存は、私たちがWindows Vistaにたどり着いた方法です。
彼は、経験上、ユーザーが実際に発見するバグの種類が2つのカテゴリに分類される傾向があることを書いています。 、または2）エッジケースが非常に曖昧であるため、そもそもそれらをカバーするためのテストを書くことを誰も考えなかったであろう。彼と彼のチームがFogBugzで修正したバグのごく一部のみが、単体テストで検出された種類のバグであると述べています。 （今はその記事を見つけることができませんが、誰かが私が言っていることを知っている場合は、ここへのリンクを自由に編集してください。）
そして、特にプロジェクトが多くの単体テストを持つ非常に大規模なプロジェクトに成長したときに、それが価値があるよりも問題になる可能性がある方法を書いており、 その後、意図的に何かを変更して、非常に多くの壊れたプロジェクトが発生します）ユニットテスト 彼は特に、ユニットテストがジョエルテストに13番目のポイントとして追加しなかった理由として、ユニットテストが引き起こす可能性のある問題を使用しています。
ジョエル・スポルスキー自身 2009年にこの質問に答えた ：
Joel：テスト駆動開発についての議論があります...すべてのユニットテストがあるとしたら、その種のものです...多くの人が書いています私にとって、Joel Testを読んだ後、「13番目のものが必要です：ユニットテスト、すべてのコードの100％ユニットテスト」。
そして、それは私があなたが必要としないかもしれない何かについてほんの少しあまりにも教義的であるように私を襲います。同様に、アジャイルプログラミングの全体的なアイデアは、必要になる前に行うのではなく、必要に応じてページフォールトを行うことです。多くの場合、すべての自動テストはあなたを助けにはならないように感じます。言い換えれば、コードが実際に機能することを保証するために、非常に多くのユニットテストを記述し、機能しないかどうかを確認します（機能しない場合）テストを書く]は、実際にはまだ動作します...わかりません。私はそれをうまく表現していないので、このようなメールを受け取るつもりです。しかし、もしチームが本当にユニットテストの100％のコードカバレッジを持っていたとしたら、いくつかの問題があるように思います。 1つは、ユニットテストを作成するのに膨大な時間を費やしていたはずであり、品質を向上させるためにその時間を支払うことができるとは限りませんでした。つまり、品質が向上し、何も壊さないという自信を持ってコードの内容を変更できるようになりますが、それだけです。
しかし、私が発見した単体テストの本当の問題は、コードの進化に伴って行う傾向のある変更のタイプが、一定の割合の単体テストを破る傾向があることです。時々、コードに変更を加えて、どういうわけか、ユニットテストの10％を壊すことがあります。意図的に。何かのデザインを変更したので...メニューを移動し、そのメニューに依存しているすべてのものが...メニューが別の場所にあります。そして、これらすべてのテストが失敗します。そして、コードの新しい現実を反映するために、これらのテストに参加して再作成できる必要があります。
つまり、プロジェクトがますます大きくなるにつれて、最終的にユニットテストがたくさんある場合、それらのユニットテストを維持し、最新の状態に保ち、維持するために必要な投資額が増えるという結果になります。それらが通過すると、あなたがそれらから得る利益の量に不釣り合いになり始めます。
確かに答えられるのはジョエルだけだった。しかし、いくつかの理由/観察を試すことができます。
まず第一に、テストはジョエルのテストから欠落していません
- テストは12ステップで2回直接言及されます（10および12）
- ビルドの存在は最初のポイントの1つです。ビルドするという考えは、それらが壊れるかどうかを確認するための容量を取得することなので、ここではテストについても話します。
次に、（私が理解しているように）Joel Testの全体的な考え方は、はい、いいえの質問にすばやく答えることです。 「TDDをしますか？」正確に収まりません（答えは「一部の人」、「コードのその部分について」、「ユニットテストを行う」など）。
第3に、「ジョエルでさえ」「価値のある唯一のもの」（ちなみに「あなたがプログラムする」はその上にない）を指していると誰もが言ったことはないと思います。将来のチームメンバーとして、または顧客としても、ソフトウェアチームと連絡を取りました。これは、自分のIT部門の良さ/悪さについての手がかりを探していた、私の周りの非技術者に渡したリストです。それはすべてではありませんが、3分で打つことは本当に悪いです。