0

システムのクロックのテストを扱う JUnit クラスがあります。時計には、jump(long milliSeconds基本的に時計を指定された時間にジャンプさせるメソッドがあり、時計のインスタンスフィールドをcurrentTimeジャンプメソッドに渡されたパラメーターに設定します。

したがって、3 つの JUnit メソッドがあります。最初の例では、クロックで何も呼び出していないため、クロックの現在の時刻が 0 であることを単純にテストしています。あとは、時計を指定時刻に一度ジャンプさせると、現在の時刻に正しく反映されることをテストしているところです。最後に、jump メソッドを数回呼び出して、各ジャンプの後、現在の時刻が正しいかどうかをテストしています。

私が抱えている問題は、JUnit テストが成功する場合と失敗する場合があることです。上記の 3 つの JUnit メソッドを 1 回実行すると、成功したとします。それはいいです。次に、3 つをもう一度実行すると、時計の現在の時刻が 0 ではなく、最後のテストで呼び出された最後のジャンプであるため、最初の 1 つが失敗します。

3 つの JUnit メソッドをすべて順番に実行した後、テストを再度実行した場合に何をしたかを「覚えていない」と考えたため、これについて混乱しています。

では、現在の時刻を 0 に初期化する必要があり@Before setUp()ますか? 問題は、上記が発生するのはたまにしかないということです。5分待ってからもう一度実行すると。それはうまくいきます。その後、すぐにもう一度実行すると、同じエラーが発生します。

おそらく、Clock クラスを final として宣言したという事実と関係がありますか? または、Singleton デザイン パターンを適用したことはありますか?

4

2 に答える 2

1

Clock をシングルトンとして設計しました。Clock のインスタンスは、クラスローダーごとに 1 つだけです: Clock.INSTANCE。したがって、明らかに、テストのメソッドがクロックの状態に影響を与える場合、次のメソッドはこの新しい状態でこのクロックを見つけます。

シングルトンがアンチパターンである理由の 1 つを再発見しました。それは、単体テストが難しいということです。すべてのテストでは、クロックについて何も仮定せず、テスト前に既知の初期状態に置く必要があります。

または、テストのセットアップでインスタンス化できる単純な古い Java オブジェクトとして Clock を設計し、IOC コンテナを使用して実行時に Bean に Clock の一意のインスタンスを注入することもできます。

また、単体テストは互いに独立していることになっていることに注意してください。すべてのテストを実行したい場合もあれば、そのうちの 1 つだけを実行したい場合もあり、それらは任意の順序で実行できる必要があります。

于 2012-11-18T17:15:02.643 に答える
0

JUnit では、テストメソッド呼び出しの順序は保証されていません。これについては、JUnit のFAQセクションで説明されています。

実装はシングルトンを使用しているため、JUnit がテストを実行する順序の前に公開されると、テスト結果に影響します。

テストが相互に依存することは良い習慣ではありませんが、TestNG を使用できることを確認する必要がある場合。

これを修正するには、単純な POJO クラスを使用し、一部の DI フレームワークでそれを処理させます。それが制約であり、クラスをそのまま保持する必要がある場合は、TestNG でテストするか、必要な順序になるようにテストを書き直してください。すなわち: 良いテストは、指定された時間が短いと例外がスローされる可能性があることを確認できると思います。

于 2012-11-18T17:41:37.793 に答える