私は大企業で働いていますが、デスクトップLOBアプリケーションを開発するたった2人のチームです。私はかなり長い間TDDを研究してきましたが、大規模なアプリケーションでその利点を実現するのは簡単ですが、アプリケーションの規模でTDDの使用を開始する時間を正当化するのは困難です。

テストの自動化、保守性の向上などの利点を理解していますが、私たちの規模では、すべてのコンポーネントの基本的な単体テストでさえ、開発時間を簡単に倍増できます。私たちはすでに極端な締め切りに恵まれていないため、どの方向に進むべきかわかりません。それ以来、アジャイルな反復開発などの他のプラクティスが完璧になりますが、小さなチームでのTDDの生産性のトレードオフにやや引き裂かれています。

TDDの利点は、非常に厳しいスケジュールの小さなチームでの余分な開発時間に値するでしょうか？

truthい真実は、最初はあなたを遅くするということです。新しいプロセスやプラクティスは、立ち上がるのに時間がかかります。私の経験では、TDDは、メンテナンス、バグ修正、および拡張と同様に、初期実装では支払いを行いません。他の人にとっては即時の支払いがあることを知っているので、それは各人の現在のコーディングスタイルに依存します。

私はTDDの大きな支持者ですが（現在の仕事に持ち込みました）、実践を探求し理解するために、少し息をする部屋（締め切り/タイムライン）が必要だと思います。

チームが小さければ小さいほど、TDDをすぐに活用できます。チームの規模が6〜3の場合、この支払いを見ました。

あなたが話している余分な開発時間は幻想かもしれません。

TDDが標準の単体テストと異なる点は、テストを行うためだけに使用されないことです。

TDD is a new way of developing software。それは私が知っている最良の方法の一つです。

したがって、プロジェクトのサイズとは関係ありません。コードの最初の行から利点を抽出します。

• メンテナンスと再利用が簡単になるようにコードを強制的に構築します。ソフトウェアの設計を推進します。
• リファクタリングが高速で安全で楽しいものになります。
• タスクの実装を非常に簡単にする機能の小さなチャンクを書くのに役立ちます。
• 通常、デバッグタスクの頻度を減らします。

一般的な誤解、私はそれを叫びましょう：

TDDのテストは機能のためのものです

EOM。

編集：詳しく説明しましょう：「すべてのコンポーネントまたはコンポーネントのユニットテストを書く」は、TDDではなくユニットテストです。私は1人のチームでTDDを日常的に使用しており、大きな成功を収めています。その見返りは並外れています。

TDD、ユニットテストの技術（公式サイト）に関するすばらしい本があります。良い部分は、「ユニットテストを組織に統合する」-第8章と「レガシーコードを扱う」-第9章などの問題を検討している章全体があることです。 、私の経験に基づいて、これは良い出発点だと思います。

答えを得るために必要な質問がいくつかあります。

1. コードのバグを修正してリリースした後、どれくらいの時間を費やしますか？これを定量化できる場合は、これらのバグの発生を防ぐのに役立つテストを作成するのにかかる「余分な」時間に等しいか、それを超えることがあります。

2. コードをリファクタリングしたり、新しい機能を追加したりするために、見かけ上簡単な編集が、明らかに無関係な何かを壊した頻度はどれくらいですか？繰り返しますが、テスト範囲が良好であれば、これらは削減できます。

これらに正確な数字を付けられない場合でも、とにかくこの時間を費やしていることを示すことができるので、「前もって」それを費やし、（で​​きれば）より安定した製品になる可能性があります。

チームでテストを採用し始めることについて人々が私に話すとき、私は常に最初にテストがどのように実行されるかをチェックします。多くの場合、チームには継続的なビルドがありません。リソースが限られている場合は、CIサーバーをセットアップすることが、テストに本格的に取り組むための前提条件であることをお勧めします。

セットアップが完了したら、TDDの練習を始めてください。システムがテストを念頭に置いて開発されていない場合、既存のコードをテスト可能にするのに苦労する可能性があり、再構築するには費用がかかることに注意してください。

TDDで始めるのに簡単な場所を探すことから始めます-わずかな依存関係を持つ新しいクラスまたはモジュール。多くの場合、ユーティリティクラスとデータ構造は良いものです。

コードがあなたのコードに対する考え方をどのように変えるかについて感じ、あなたが作り出すコードがどれほど優れているか、そしてそのコードについてどれほど自信があるかに注意してください。

私は質問に実際に答えていないことを知っていますが、私のポイントはあなたが莫大な追加費用なしでこれらすべてを行うことができるはずだと思います。最初の例を使用することで、プロジェクトの利点をよりよく理解できます。

結論-開発は遅くなりますが、欠陥はほとんどなく、バグ修正の時間はずっと短くなります。

ビヘイビアドリブン開発がすぐに利益をもたらすと私は思うのですが、テストドリブン開発がそうなるかどうかはわかりません。

行動駆動型開発では、別の方法でチケットにアプローチします。ビジネスパーソンと一緒に座って、この機能のチャンクが持つべき振る舞いを定義するために彼らと協力します。これについては、ブログのエントリで説明します（投稿タイトル：Writing Behaviors）。

ビジネスパーソンまたは誰とでも座って、あなたと彼らがその機能に満足するために誰もがシステムが何をする必要があるかをよりよく理解するのを助けます。実施しているQAプロセスで受け入れられるために必要なこと。

テスト基準を定義し、それらのテスト基準を自動テストスイートに書き込むことで、やり取りの量を減らすことができます。何かを見逃したため（機能的に見逃したため、または、それについてあなた）。

また、他の人のチームの認識にも役立ちます。座ってシステムで何をする必要があるかを定義すると、「すべてを過度に設計し、要求していないことに時間を費やすバカ」から、 「便利な機能を考え出すスマートな人々」。

TL; DR：「顧客」に焦点を合わせているため、行動駆動型開発ではすぐに改善が見られる場合があります。私にとって、テスト駆動開発とは、「誰も」気にせず、あまり明らかなビジネス上の利益をもたらさないコードベースの内部をテストすることです。（Behavior Driven Developmentにはすぐに変化があります。エンジニアは突然、「顧客」またはビジネスアナリストと面談して、これを正しくしようとしています-これは良いことだと思われるはずです。 、彼らはフィーチャーXについての会議を開いています。つまり、その面で進歩があります！」