TDD の実際の利点 – Axol のブログ

で 以前の記事私は、(経験豊富なエンジニアによってさえも) あまりにも頻繁に目にする、TDD を擁護するために使用されるいくつかのひどい議論を徹底的に論破しました。私はその文章の中で、最終的には TDD にとってより良い議論を行うつもりだと言いました。それで、それを今やろうとしています。

TDD はエッジケース向けのテストの作成を奨励します

ここでは、ほとんどの擁護者が行うような「保証する」ではなく、「奨励する」という言葉を使用していることに注意してください。これが私が従う経験則です。 モジュール内のコード行をコメントアウトし (まだコンパイルおよび実行できると仮定して)、すべてのテストが依然として合格する場合は、何かが間違っています。 これもよく見かけます。 TDD がこの点に注意を向けているという有力な主張があります。 ただ 既存のテストに合格するのに十分なコード。エッジケースの処理を実装したい場合は、最初にそのためのテストを作成する必要があります。

ただし、それは万能薬ではありません。明らかに、誰かが最初にエッジケースに気づく必要があります。コードの大部分をすでに記述していないと、これを行うのは難しい場合があります。次に、開発者がより多くの作業を必要とする場合でも、開発者が TDD を厳密に遵守していることを確認する必要がありますが、これはそれ自体の課題です。

TDDは実装をアウトソーシングする際のガードレールとして使用可能

場合によっては、チームの一員であるかどうか、あるいは会社の一員であるかどうかに関係なく、実際の実装を別の開発者に行ってもらいたいことがあります。文書化されたドキュメントは要件を伝えるだけですが、テストではインターフェイスの形状と関連するデータ型が強制されます。

実装をテストしたい場合 として 従来の開発では手動テストを繰り返し実行する必要があり、多くの時間を無駄にします。一方、事前にテストを作成しておけば、いつでもすぐにスイートを実行できます。

これはあまり語られていない非常に良い点です。あなたが神レベルの開発者でない限り、開発中のいくつかの時点で「チェックイン」して、実装がどの程度正しいかを確認する必要があります。テストがない場合は、これを手動で行う必要があります。あなたはどうか知りませんが、非常に多くのケースを手動でテストするのは非常に面倒です。私は時々このことで罪を犯します。これは陥りやすい罠です。従来の開発に固執しすぎて、実際に何かを作成できるときにテストを書くのに「時間を無駄にする」ことを恐れてしまいます。退屈ではありますが、長い目で見れば時間とフラストレーションを節約できます。

TDD は、優れたテストを書くことに慣れていない人々を訓練するために使用できます

これが「補助輪」論です。考え方としては、文章を書くことを学んでいない人もいるということです 良い 彼らは怠け者で、変化に抵抗し、カバレッジメトリクスの奴隷であり、モックに夢中で、実装の詳細なしでインターフェイスを考えることができないため、または教育によって失敗したため、テストを行う必要はありません。

原因が何であれ、一部の人々は実際に行動をまとめるために裏側をブートする必要があることに同意せざるを得ません。 「」のチームでこれを何とか強制できれば。テスト不足」開発者を怒らせるのではなく、あなたにもっと力を与えてください。しかし、彼らは改善したいという真の願望、適切なトレーニング、サポートを持っていなければなりません。そうでなければ、これはうまくいきません。彼らは最初にひどいテストを書いてから、通常の方法に戻ります。

TDD は、API/クラス/関数の構造が結晶化しているときに最適です

プログラミングの仕事には大きく分けて3種類あります。

• グリーンフィールド: これは、まったく新しいプロジェクトをゼロから開発するときです
• ブラウンフィールド: 既存のプロジェクトに機能を追加する場合
• メンテナンス: バグ修正、リファクタリング、パフォーマンスの改善など

メンテナンス TDD に適しています。メソッドの機能を変更する前にテストを変更しても害はありません (変更の範囲が巨大なものではない場合)。バグを修正する前に、最初にテストを作成してバグを証明することは、非常に適切です。コンポーネントのインターフェイスに大幅な変更を加えることはほとんどないため、TDD の大きな欠点 (コード構造の変更に伴うテストの書き換えに時間の無駄が生じる) は当てはまりません。

ブラウンフィールド 仕事も TDD には適していますが、そうではありません。それは、新機能の複雑さとコードベースの拡張性によって異なります。最善の判断を下す必要があります。機能によって既存のモジュールに大幅な変更が必要と思われる場合、私は従来の開発に頼るでしょう。ただし、この新機能を実装するための穏やかな道筋が見えれば、TDD でさらに多くのメリットを享受できる可能性があります。

グリーンフィールド TDD にとって、開発は (最初は) 大きな禁物です。自分のインターフェイスがどのようになるかについて、どれだけ自信があるかは関係ありません。 あなたはそれほど上手ではありません。新しいプロジェクトの探索段階でコードを作成すると、自分が知っていると思っているすべてのことが変更され、テストを何度も書き直すことで正気を損なうことになります。 TDD アイドルがどれだけその利点を誇示しても、これを行わないでください。

しかし、テストを書き直すことが多すぎると、TDD を適切に実践していないことになります。」 聞きたくないです。初期テストが、新しいプロジェクトの未知の部分をマッピングする際に最終的にテストを書き直す必要がほとんどないようなものである場合は、次の 1 つ以上が当てはまります。

• このプロジェクトは、あなたが以前にやったことや見たことのあるものと非常によく似ており、その場合、私はそれを「グリーンフィールド」とは呼びません。
• このプロジェクトは非常に単純で、インターフェイスやテストを思いつくのは簡単です。必要に応じて、これに TDD を使用することもできますが、それは実りあるアプリケーションというよりは練習になります。
• テストは非常に高レベルで、より深いモジュールからは遠く離れています。これは、TDD の利点を活用していないことを意味します。これらのテストは任意の順序で記述できますが、大きな違いはありません。
• 今回は幸運なことに、探索により最初の推測と同様の結果が得られました。
• あなたは神レベルの開発者です。その場合、パラダイムを気にする必要さえありません

代わりに、API が完了するまで待つ必要があります。 結晶化した テストを書き始める前に。このとき、TDD の上記の利点が得られ、欠点は最小限に抑えられます。これは本当の TDD ではない、と尻込みするかもしれません。ただ、騙されたということだけは知っておいていただきたいのです。以下のグリーンフィールドプロジェクトに取り組んでいると言う人は誰でも 真実 TDD は非常に非効率なプログラマーであるか、徹底的に嘘をついています。

ふう！それだと思います。このトピックについてはあまりにも二極化しているので、このことを胸から取り除く必要がありました。おそらくそれは変わらないだろうが、私は人々にそうしてもらいたい 理解する 彼らの反対 前に 彼らを解雇すること。

否定論者は、TDD は真剣に受け止められるべきではない、単なる周辺パラダイムだと考えています。それをカルトだと見る人もいますし、時にはそう見えることもありますが、どのパラダイムにも独断主義者がいます。プログラミングは初期段階にあるため、真剣に検討するまでは、型破りな方法論を軽視しないでください。

擁護者は欠点を軽視し、直面する反対意見に正直に関与しないことがよくあります。彼らは経験に基づいて議論し、具体的な実践的な処方箋を作成するのではなく、理論に後退し、そこで議論を行うでしょう。

皆さんはそれよりも賢いです（私は願っています）。そしていつかあなたも私と同じくらい賢くなるかもしれません。