コードカバレッジは未使用のメソッドを強調表示します-どうすればよいですか？
既存のJavaプロジェクトのコードカバレッジを増やす必要があります。
コードカバレッジツール（ EclEmma ）が、どこからも呼び出されないメソッドをいくつか強調表示していることに気付きました。
私の最初の反応は、これらのメソッドの単体テストを作成するのではなくではないが、ラインマネージャー/チームにそれらを強調し、これらの関数が開始する理由を尋ねると。
最善のアプローチは何でしょうか？それらのユニットテストを書くか、なぜそこにあるのか疑問に思いますか？
- 削除。
- コミット。
- 忘れる。
根拠：
- 死んだコードは死んだ。まさにその説明によって、それは目的を持っていません。ある時点で目的があったかもしれませんが、それはなくなったので、コードはなくなっているはずです。
- バージョン管理により、（私の経験では）
珍しい誰かが後でそのコードを探して出てくるユニークなイベントは、それを取得できます。 - 副作用として、何もせずにコードカバレッジを即座に改善します（デッドコードがテストされている場合を除きます）。
コメントからの警告：最初の答えは、コードが疑いもなく、死んでいることを徹底的に検証したと想定していました。 IDEには誤りがあり、実際には死んでいるように見えるコードが呼び出される可能性のある方法がいくつかあります。確実でない限り、専門家に相談してください。
他のすべての回答は、問題のメソッドが実際には使用されていないという前提に基づいています。ただし、質問には、このプロジェクトが自己完結型であるか、何らかのライブラリであるかは明記されていませんでした。
問題のプロジェクトがライブラリである場合、使用されていないように見えるメソッドがプロジェクトの外部で使用されている可能性があり、それらを削除すると他のプロジェクトが破損します。ライブラリ自体が顧客に販売されたり、公開されたりすると、これらのメソッドの使用状況を追跡することさえ不可能になる場合があります。
この場合、4つの可能性があります。
- メソッドがプライベートまたはパッケージプライベートの場合は、安全に削除できます。
- メソッドが公開されている場合は、機能を完全にするために、実際に使用しなくてもその存在を正当化できます。ただし、テストする必要があります。
- メソッドがパブリックで不要な場合、それらを削除すると重大な変更が発生します。ライブラリが semantic versioning に従っている場合、これは新しいメジャーバージョンでのみ許可されます。
- または、パブリックメソッドを廃止して後で削除することもできます。これにより、APIコンシューマーが次のメジャーバージョンで削除される前に、廃止された関数から移行するための時間が与えられます。
まず、コードカバレッジツールが正しいことを確認します。
インターフェイスへの参照を介して呼び出されているメソッド、またはクラスが動的にどこかにロードされている場合に、それらがピックアップされない状況がありました。
Javaは静的にコンパイルされるため、メソッドを削除してもかなり安全です。デッドコードを削除することは常に良いことです。実行時にそれらを実行するクレイジーリフレクションシステムが存在する可能性があるため、最初に他の開発者に確認してください。それ以外の場合は削除してください。
最善のアプローチは何でしょうか？それらの単体テストを書くか、なぜそこにあるのか疑問に思いますか？
コードを削除するのは良いことです。
コードを削除できない場合は、コードを @ Deprecated としてマークし、メソッドを削除することをターゲットにしている メジャーリリース を文書化できます。その後、「後で」削除できます。当面は、それに依存する新しいコードを追加しないでください。
非推奨のメソッドに投資することはお勧めしません。カバレッジターゲットを達成するだけの新しい単体テストはありません。
2つの違いは、主にメソッドが 公開インターフェース の一部であるかどうかです。公開されたインターフェースの一部を任意に削除することは、インターフェースに依存していた消費者にとって不愉快な驚きとなる可能性があります。
私はEclEmmaと話すことはできませんが、私の経験から、あなたが注意する必要があることの1つは反射です。たとえば、テキスト構成ファイルを使用して、アクセスするクラス/メソッドを選択する場合、使用/未使用の区別が明確でない可能性があります（私はそれをつなげて何度も焼かれています）。
プロジェクトが依存関係グラフのリーフである場合、非推奨のケースは弱体化されます。プロジェクトがライブラリの場合、非推奨のケースがより強くなります。
会社で mono-repo を使用している場合、削除はマルチリポジトリの場合よりもリスクが低くなります。
l0b で示されているように、メソッドがソース管理ですでに使用可能である場合、削除後にそれらを回復することは簡単です。本当にそうする必要があるか心配している場合は、削除した変更を必要に応じて復元できるように、コミットを整理する方法を検討してください。
不確実性が十分に高い場合は、コードを削除するのではなく、コードをコメントアウトすることを検討できます。これはハッピーパス（削除されたコードが復元されない場所）での余分な作業ですが、復元が簡単になります。私の推測では、数回焼き付けられるまではストレートデリートを優先する必要があります。これにより、このコンテキストでの「不確実性」の評価方法に関する洞察が得られます。
なぜそこにいるのか？
伝承を捕らえるために費やされた時間は必ずしも無駄ではありません。私は2つのステップで削除を実行することで知られています。最初に、コードについて学んだことを説明するコメントを追加してコミットし、次にコード（およびコメント）を削除します。
ソースコードで伝承をキャプチャする方法として、 建築決定記録 に類似したものを使用することもできます。
コードカバレッジツールは、すべてを知っている、すべてを見るものではありません。ツールがメソッドが呼び出されていないと主張しているからといって、それがis n'tが呼び出されたという意味ではありません。リフレクションがあり、言語によっては、メソッドを呼び出す他の方法がある場合があります。 CまたはC++では、関数名またはメソッド名を構成するマクロがあり、ツールが呼び出しを認識しない場合があります。したがって、最初のステップは次のようになります。メソッド名および関連する名前をテキスト検索します。経験豊富な同僚に聞いてください。実際に使用されている場合があります。
不明な場合は、各「未使用」メソッドの先頭にassert（）を配置してください。たぶん呼び出されます。またはロギングステートメント。
たぶんコードは実際に価値があります。同僚が2週間取り組んできた新しいコードで、同僚が明日オンにする予定だった可能性があります。明日追加されるので今日は呼ばれません。
おそらく、コードは実際に価値のあるパート2です。コードは、問題が発生していることを見つけることができる非常に高価なランタイムテストを実行している可能性があります。実際に問題が発生した場合にのみ、コードがオンになります。貴重なデバッグツールを削除している可能性があります。
興味深いことに、考えられる最悪のアドバイスは「削除、コミット、忘れる」です。最高評価です。 （コードレビュー？あなたはコードレビューをしませんか？コードレビューをしなければ、いったい何をプログラミングしていますか？）
ソフトウェアが実行される環境によっては、メソッドが呼び出された場合にログに記録できます。適切な期間内に呼び出されない場合は、メソッドを安全に削除できます。
これは、単にメソッドを削除するよりも慎重なアプローチであり、障害の影響を受けやすい環境で実行している場合に役立つことがあります。
専用の#unreachable-code削除候補ごとに一意の識別子を持つスラックチャネル。これはかなり効果的であることが証明されています。