通常の「コードの機能行」と「コードのテスト行」の比率はどのくらいですか？
私はTDDアプローチにかなり慣れていないので、最初の実験では、1行の関数コードを書くことは、約2〜3行のテストコードを書くことを意味するということです。したがって、1000 LOCを作成する場合、テストを含むコードベース全体は、約3500 LOCのようになります。
これは正常と見なされますか？あなたが書くコードの比率はどれくらいですか？
1：3はTDDでは正常です。
私の経験から、そして私が覚えている他の引用からも。
さまざまなコーディングスタイルと言語に基づくバリエーションがあります。ただし、使用する言語に関係なく、最大のバリエーションはあなたです。
ロバートマーティンはかつて言った：
「テストがより具体的になるにつれて、コードはより一般的になります。」
それは私に考えさせられました。より具体的なテストは、より多くのテストコードを意味します。より一般的な量産コードはコードが少ないことを意味するため、コードが進化するにつれてテスト/コード比率が上がるはずです。
しかし、待ってください、それも良くありません。特定のケースでは、たとえば特定のアルゴリズムを定義する場合、いくつかの "if"を含む6〜10行のコードがあり、しばらくの間、場合によっては2〜3回の再帰があります。私はあなたに言うことができます、そのコードはおそらく100行以上のテストコードを持つでしょう。
実際のプロジェクトでは、いくつかのアルゴリズムよりも大きなもので、テストとコードの比率は1：1と2：1の間のどこかにあるはずです。 2：1を超える場合は、リファクタリングまたは削除する必要があるテスト（またはテストが難しいコード）があるというにおいです。運用コードと同じ量の注意とリファクタリングをテストに投資する必要があります。
とにかく、あなたの質問に対する最良の答えは多分 "Cyclomatic Complexity" でしょう。メソッドの循環的複雑度が高いほど、すべてのケースをカバーするためにメソッドを書く必要がある指数関数的により多くのテストになります。
この比率は、メソッドのサイズによって異なります。メソッドのサイズは、プログラミングスタイル、言語、問題ドメインによって異なります。
メソッドが短い場合は、3：1が妥当です。メソッドが長い場合は、3：1が有利です。
だから、あなたの質問に答えるには、それは異なります。 :-)
ソフトウェアクリティカルなアプリケーションの場合、通常の比率は、10個の機能LoCごとに1日のテストです。
そして、これはテストではなく仕様に関するTDDを数えていません。
テストコードのサイズは、「実際の」コード全体のサイズの約半分です。それ以外の場合は、テストが複雑すぎるか、コードがテストしにくいか、コードが密度が高いか、複雑すぎるかを示しています。
または、単にテストしすぎて、リターンの減少に時間を費やしている。
"ユニットテストが不適切または不要な場合はいつですか？" も参照してください。