これを処理するための個別のツールはわかりませんが、JUnitには@Testアノテーションにtimeoutというオプションのパラメーターがあります。
2 番目のオプション パラメータである timeout は、指定されたクロック時間 (ミリ秒単位で測定) よりも長い時間がかかる場合にテストを失敗させます。次のテストは失敗します。
@Test(timeout=100) public void infinity() {
while(true);
}
したがって、追加の単体テストを作成して、特定の部分が「十分に速く」動作することを確認できます。もちろん、特定のタスクの実行にかかる最大時間をどうにかして最初に決定する必要があります。
-
2 番目の質問が該当する場合、私が目にする問題は次のとおりです。
- 実行環境によって変動します。
常に多少の変動はありますが、それを最小限に抑えるために、Hudson または同様の自動化されたビルドおよびテスト サーバーを使用してテストを実行します。そのため、環境は毎回同じになります (もちろん、Hudson を実行しているサーバーがすべてを実行する場合)他の種類のタスク、これらの他のタスクは結果に影響を与える可能性があります)。テストの最大実行時間を決定するときは、これを考慮する必要があります (「余裕」を残しておくと、たとえば、テストの実行に通常よりも 5% 多くかかる場合でも、すぐに失敗することはありません)。 .
- Java のマイクロ ベンチマークには大きなばらつきがあるため、変更を検出するにはどうすればよいですか。
Java のマイクロベンチマークはめったに信頼できません。統合テスト (単一の http 要求の処理など) でより大きなチャンクをテストし、合計時間を測定します。時間がかかりすぎてテストが失敗した場合は、プロファイリングによって問題のあるコードを分離するか、テストの実行中にテストの別の部分の実行時間を測定してログアウトし、どの部分が最も時間がかかっているかを確認します。
- Caliper が結果を収集する場合、結果をカスタム形式で保存できるように Caliper から結果を取得する方法。キャリバーのドキュメントが不足しています。
残念ながら、私はキャリパーについて何も知りません。