私は定期的に TDD を使用してライブラリの 100% のカバレッジを達成していますが、常にではありません。また、テストされておらず、カバーされていないアプリケーションの部分が残っているように常に見えます。
次に、テストがほとんどなく、カバレッジもほとんどないレガシー コードから始める場合があります。
あなたの状況と、少なくともカバレッジを改善するために何が機能したかを教えてください.
単体テスト中にカバレッジを測定していると仮定していますが、他の手法を使用しているかどうかを教えてください。
コードを削除します。
これは皮肉なことではありませんが、実際には深刻です。ごくわずかなコードの重複や、実行できないコードを見つけるたびに、それを削除しました。これにより、カバレッジが向上し、保守性が向上しました。
これは、古いコード ベースと新しいコード ベースのカバレッジを拡大する場合により適していることに注意してください。
「カバーされたコードとテストされたコード」を読んだと思いますよね？
その質問で述べたように、
100% のブロック カバレッジ + 100% のアーク カバレッジ + 100% エラーのない少なくとも 1 つのパスの直線コードを使用しても、より多くのバグを示す方法でパス/ループを実行する入力データがまだ存在します。
ここで、EMMA に基づくeclemmaを使用します。そのコード カバレッジ ツールは、100% コードが常に可能であるとは限らない理由を説明しています。
したがって、これら 4 つのケースはすべて、コード カバレッジの向上につながるリファクタリングの候補となる可能性があります。
さて、私はフランク・クルーガーの答えに同意します。カバーされていないコードの一部は、実際に削除するコードを含む、リファクタリングが必要であることを示している可能性もあります;)
私たちは Perl を使っているので、Devel::Coverはとても役に立ちました。単体テスト中のステートメントごとのカバレッジ、分岐カバレッジ、条件付きカバレッジ、および POD カバレッジなどを表示します。「100%」は識別しやすい緑色、低レベルのカバレッジは黄色と赤色の HTML 出力を使用します。
編集：物事を少し拡張するには：
私が取り組んできたプロジェクトに最も大きな影響を与えた 2 つのことは次のとおりです。
FIT テストにより、コード カバレッジが改善されました。まったく別のタックであるため、それは素晴らしいことです。
背景: 従来のコードと新しいコードが混在しています。新しいもののユニット/統合テストを可能な限り試みますが、Hibernate/Postgres に移行し、OODB から離れているため、レガシー コードをテストする意味はあまりありません。
ご存じない方のために説明すると、FIT はユーザーの視点からソフトウェアをテストする方法です。基本的に、HTML テーブルで目的の動作を指定できます。テーブルは、ソフトウェアに対するアクションと目的の結果を指定します。私たちのチームは、アクションをコードに対する呼び出しにマッピングする「グルー コード」(別名 FIT テスト) を作成します。これらのテストは、単体テストと比較して「空間から」のビューで動作することに注意してください。
このアプローチを使用することで、コード カバレッジが数パーセント向上しました。追加のボーナスは、これらのテストがバージョン間でブリッジすることです。これらのテストはレガシー コードをテストしますが、後で新しいコードをテストします。つまり、ある意味で回帰テストとして機能します。