2

静的関数のモックを含む、モックを多用する非常に遅いJUnitテストがいくつかあります。単一のテストには20〜30秒かかり、「mvnテスト」全体には25分かかります。

時間が無駄になっている場所を分析したいのですが、プロファイリングの経験がほとんどありません。

依存するモックオブジェクトの初期化には時間がかかりすぎると思います。

2つの質問：

1）時間を無駄にしている方法で数字をすばやく取得するにはどうすればよいですか？複雑なパワーユーザーツールは必要ありません。数値を取得するための基本的なものだけです。（私たちが行うような嘲笑が悪であるという証拠）

2）どのような設計上の欠陥がそのような悪いタイミングを生み出す可能性があるかについてのアイデアはありますか？モックサービスを呼び出す必要があるJSFバッキングBeanをテストします。おそらく、バッキングBeanに入力検証またはリファクタリングされていないビジネスロジックがあるかもしれませんが、それを変更することはできません（plsはそれについてコメントしません;-)）

ad 2）たとえば、1つのテストには@PrepareForTestを使用したテスト用に準備される約30（！）のクラスがあります。これは良いことではありませんが、理由を説明することはできません。

4

1 に答える 1

3

これに関する私の意見は次のとおりです。

  1. ApacheCommonsStopWatchクラスのような単純なものを使用してみてください。これはコード内のボトルネックを見つける簡単な方法であり、通常、最初のボトルネックが何であるかを見つけると、残りのボトルネックを見つけるのが簡単になります。過度に複雑なプロファイリングツールを構成しようとして時間を無駄にすることはほとんどありません。

  2. 完全にモックされた単体テストでこのようなパフォーマンスの欠陥があるのは奇妙だと思います。推測すると、1つまたは2つのモックされたコンポーネントが欠落していて、データベースまたは外部Webサービスが実際には知らないうちに呼び出されていると言えます。もちろん、私はPowerMockを使用していないので、間違っている可能性があります。静的メソッド。これが現在の最大の設計上の欠陥であり、コードに適切なテストカバレッジを提供する上での最大の障害です。じゃあ何をすればいいの？2つのオプションがあり、静的メソッドをより簡単にモックできるクラスメソッドにリファクタリングできます。もう1つのオプションは、静的メソッドをクラスオブジェクトラッパーでラップし、代わりにラッパーをモックすることです。私は通常、静的メソッドがソースを持っていないサードパーティのライブラリからのものである場合にこれを行います。

  3. one test has about 30 (!) classes to be prepared for test with @PrepareForTest. This cannot be good, but I cannot explain why.これは本当に、あなたが完全にやりすぎのメソッドを持っているかもしれないように聞こえます！ これは、約99％のケースで、単一のメソッドには依存関係が多すぎます。おそらく、この方法は、より簡単にテストできる別の方法に分けることができます。

お役に立てれば。

于 2012-01-26T12:20:59.870 に答える