1

より大きな製品で Test First Design アプローチに従うことによって達成できる実現可能性と現実的な利益について疑問に思っていました。

私は、コーディングに飛び込む前にスコープを決定することを強く信じていますが、より大きな製品の場合、 TDDが成り立つかどうかはよくわかりません.

より大きな製品に伴う現実的な問題:
1. 製品のサイズにより、すべてのテスト ケースを維持することが非常に困難になります。
2. ユニットの境界が徐々に不明確になり、異なるユニット間で望ましくない結合が生じることがあります。
3. ユニットのテストでは、開発された構造自体の機能を十分に発揮できない場合があります (密結合の結果の可能性があります)
。これにより、ユニットの定義が希薄になり、テスト ケースは、コードの一部を保護するという目的を果たすのではなく、単なるプロセス要件になります。

私の見解では、この製品成長の状況は、製品の成長を止めて、不要な部分を取り除くことです。製品を定義する機能のみを含むように、製品のクリーンアップを開始します。他の機能は、既に開発されているか開発中のいずれかで、アドオンとして提供できます。そして、これらの製品のコア機能セットは、ユニットの機能のみを定義する強力なユニット テスト ケースのセットを使用して保護する必要があります。

他に提案はありますか？私は現在、ユニットの結合と実際にはあまり効果のない冗長なテストケースのこの状況に直面しているので、皆さんからの連絡をお待ちしています. そして、これらすべては、ほぼ毎日成長している製品のサイズのために導入されています.

4

1 に答える 1

1
  1. TDD は、あらゆる規模のプロジェクトで機能します。個人的には、最後の計算で約 650,000 行の C Sharp を使用するシステムに取り組んでいます。変更を裏付けてリグレッションを防ぐ一連のテストがなければ、このようなサイズに近づくことはできませんでした。
  2. Test First と Test Driven (TDD) の違いを思い出してください。テスト駆動開発に従い、作成したコードをテストで駆動する場合、結合は問題になりません。TFD についても同じことは言えません。このレベルの品質を制御するのは開発者次第です。
  3. ポイント1を参照してください。実際、単体テストは、どこでも高度な機能を実現するための最善の策です。コード内のパスごとに必要なテストの数については、この記事を確認してください。統合テストを使用することもできますが、記事で指摘されているように、必要な数は必要な単体テストの数よりも多くなります。
  4. これはチーム次第です。テスト コードは、第一級市民として扱われるべきです。これは、プロジェクトがあなたが考えるほど「大規模」になる場合に特に当てはまり、わずかな後退でもコストがかかる可能性があります。

最後の質問に関しては、コア ドメイン ロジックができるだけテスト済みで安定していることを確認することをお勧めします。アプリケーションの「コア」を見つけるのは、あなたとあなたのチーム次第です。残りのインフラストラクチャはかなり緩い可能性がありますが、いずれにせよ、このレイヤーにはロジックがほとんどまたはまったくないはずです。ドメインをロックダウンすると、残りはそれに続くはずです。

于 2013-02-17T14:44:48.843 に答える