Java用のPHPUnitの「カバーされたメソッドの指定」のようなものを探しています。つまり、JUnit テスト用のアノテーションが付属するコード カバレッジ ツールで、どのメソッドがどの JUnit テストでテストされるかを指定できます。
これにより、指定されたメソッドの行のみがカウントされ、アプリケーション全体の実行されたすべての行がカウントされるわけではないため、カバーされた行のメトリックがより正確になります。
Java用のPHPUnitの「カバーされたメソッドの指定」のようなものを探しています。つまり、JUnit テスト用のアノテーションが付属するコード カバレッジ ツールで、どのメソッドがどの JUnit テストでテストされるかを指定できます。
これにより、指定されたメソッドの行のみがカウントされ、アプリケーション全体の実行されたすべての行がカウントされるわけではないため、カバーされた行のメトリックがより正確になります。
このアプローチは、プログラマーに大きな負担をかけるかのように聞こえます。テストとメソッド間の 1:1 対応を想定するか (これは、メソッドではなくクラスの動作をテストするという観点から考えるという通常のアドバイスに反します)、またはプログラマーがプライベート メソッドなどを介してルートを手動で追跡する必要があります。コードがリファクタリングされ、時間の経過とともに変更されるため、各エントリ ポイント。
これをタイプ セーフで実装する方法を理解するのは困難です。メソッドの名前変更などの迅速な自動操作では、テスト内の注釈を手動で更新する必要があります。
テスト スイートの有効性をより正確に見積もることが要件である場合、検討できる代替アプローチはミューテーション テストです。これにより、コードにフォールトがシードされ、スイートがそれらを検出できるかどうかがチェックされます。
Java で使用できるシステムは多数あります。
それらの比較はここで入手できます