TDDが高いROIを提供するエリアと、ROIが非常に低いためフォローする価値がない他のエリアはありますか？[閉まっている]

テスト駆動開発。好きです。

ただし、テストの作成にはオーバーヘッドが必要です。したがって、TDDをコードベース全体で普遍的に使用する必要がありますか、それともTDDが高いROIを提供する領域と、ROIが非常に低いためフォローする価値がない領域があります。

コードが構造的に大きく変化する可能性のある場所ではTDDを避けてください。つまり、シグネチャがめったに変更されないが、内部的にはより頻繁にリファクタリングされるメソッドのテストの山があるのは素晴らしいことですが、非常に揮発性のあるインターフェイスが劇的に変更されるたびにテストを修正する必要があります。

私が最近取り組んできたアプリは、Gui-> Presenter-> BusinessLogic-> Data Access Layerベースのアーキテクチャ上に構築されたデータ駆動型Webアプリです。私のデータアクセス層は、誰のビジネスのようにもテストされていません。ビジネスロジック層は十分にテストされています。プレゼンターはより安定した領域でのみテストされ、1時間ごとに変更されるGUIにはほとんどテストがありません。

賢明で実用的な領域で完全なテストスイートを作成することをお勧めします。実用性の低い分野では、健全性チェックを作成します。

私の経験では、ほとんどの場合、テストケースのフルセットのオーバーヘッドは確かに価値がありますが、現実的にはコードカバレッジのリターンは低下します。ある時点で、コードカバレッジを高めるためだけにテストを作成することは意味がありません。

たとえば、言語/テクノロジによっては、UIのテストは実用的ではなく、実行不可能な場合もあります。多くのテストは、おそらくユーザーが見るものに依存し、自動化することはできません。キャプチャを生成する方法が、たとえば人間が読める画像を生成することをどのようにテストしますか？

テストの完全なセットを作成するのに3日かかる場合、そのコンポーネントにバグが導入される可能性は非常に低く、関数自体の作成には30分しかかかりません。その時間が価値があるかどうかについて。たぶん、その機能の基本的な健全性チェックを書くだけで価値が得られるでしょうか？

私の一般的なアドバイスは、テストを比較的簡単に記述できる場所でコンポーネントを完全にテストすることです。ただし、テストが非常に難しいエリアの場合は、砂に線を引き、完全にテストするのではなく、より高いレベルでエリアをテストするテストを作成します。

前のcaptchaの例では、正しいサイズと形式の画像が返され、例外がスローされないことを確認するテストを書くことができます。これにより、船外に出ることなくある程度の保証が得られます。

私にとって、TDDはオーバーヘッドではありません。それはまさに私がコードを書く方法です。筆記試験は「オーバーヘッド」だと言うのはなぜですか？それはプロセスのほんの一部です。私の見解では、デバッグはオーバーヘッドであり、それはTDD-ingを開始したときに本質的に実行を停止したアクティビティです。TDD以前は、デバッグはソフトウェア作成プロセスの不可欠な部分でした。

テスト作成のためにデバッグを放棄することは非常にお買い得だと思います。

TDDが本当にひどいのは、MVCアプリでビューをテストするときです。

太いhtml文字列を返す関数をテストしているので、何かがうまくいったかどうかを確認するためだけにhtmlの解析を行っています。さらに、保守性の悪夢になる可能性があります。ある日、チェックボックスを動かしてkaboomを動かすと、テストが壊れます。

私は多くのテストでTDDが好きですが、プログラマーベルトのツールはTDDだけではありません。