「コードのテスト行」に対する「コードの機能行」の通常の比率は何ですか？

私はTDDアプローチにかなり慣れており、最初の実験では、1行の機能コードを記述することは、2〜3行のテストコードを記述することを意味します。したがって、1000 LOCを記述する場合、テストを含むコードベース全体は〜3500 LOCのようなものになります。

これは正常と見なされますか？あなたが書くコードの割合は何ですか？

TDDでは1：3は正常です。

私の経験から、そして私が覚えている他の引用から。

さまざまなコーディングスタイルと言語に基づいたバリエーションがあります。ただし、使用する言語に関係なく、最大のバリエーションはあなたです。

ロバート・マーティンはかつて言った：

「テストがより具体的になると、コードはより一般的になります。」

それは私に考えさせられました。より具体的なテストは、より多くのテストコードを意味します。より一般的な量産コードは、より少ないコードを意味するため、コードの進化に応じてテスト/コードの比率を上げる必要があります。

しかし、待ってください、それも良くありません。ある特定の場合、たとえば特定のアルゴリズムを定義する場合、「if」、しばらく、および場合によっては2〜3回の再帰を含むコードが6〜10行しかありません。コードにはおそらく100行以上のテストコードが含まれることになります。

実際のプロジェクトでは、ほんの数個のアルゴリズムよりも大きなものであるため、テスト/コードの比率は1：1から2：1の間でなければなりません。2：1を超える場合、リファクタリングまたは削除する必要のあるテスト（またはテストが困難なコード）があるというにおいです。テストでは、本番コードと同じ量の注意とリファクタリングを常に投資する必要があります。

いずれにせよ、あなたの質問に対する最良の答えは「サイクロマティックコンプレックス」でしょう。メソッドの循環的複雑さが高ければ高いほど、すべてのケースをカバーするために、より多くのテストを記述する必要があります。

比率は、メソッドのサイズによって異なります。メソッドのサイズは、プログラミングスタイル、言語、問題ドメインによって異なります。

メソッドが短い場合、3：1が妥当です。メソッドが長い場合、3：1がハイサイドになります。

だから、あなたの質問に答えるには、状況次第です。:-)

ソフトウェアクリティカルなアプリケーションの場合、通常の比率は、機能する10個のLoCごとに1日テストすることです。

そして、これはテストではなく仕様に関するTDDをカウントしていません。

テストコードのサイズは、「実際の」コード全体の約半分です。そうしないと、テストが複雑すぎたり、コードがテストしづらくなりすぎたり、コードが密集/複雑化しすぎたりします。

または、単純にテストしすぎて、収益の減少に時間を浪費しています。

「ユニットテストが不適切または不要な場合」を参照してください。

私の比率は約2-1対10-1（テストするコード）です。テストは、実装ではなく価値/行動に関するものであることを確認してください。