JUnitを使用していくつかのテストケースを書いています。そのクラスのすべてのテストケースに使用されるいくつかの静的変数を初期化する必要があります。
このために私はどちらかを使うことができます
- 静的初期化ブロックまたは
- 静的メソッド
@BeforeClass
互いに使用することの利点は何ですか?
@BeforeClass
またはstatic
イニシャライザには非常に異なるセマンティクスがあります。
静的初期化子は、JUnit ではなく JVM によって呼び出されます。静的初期化子内で例外がスローされた場合、テスト フレームワークは例外をキャッチして報告できない可能性があります。さらに、静的初期化子の呼び出し時間は、@BeforeClass
メソッドと比較して明確に定義されていません。静的プロパティ、静的メソッド、またはそのコンストラクターの 1 つへのアクセスなど、最初の実際の使用時に、クラス ローダーごとに 1 回だけ実行されます。場合によっては、これがいつになるかを把握するのが難しい場合があります。(継承を使用しない場合: いつの日か、または同僚がテスト ケースをリファクタリングする可能性があります。今日ではない場合、静的初期化子の選択により、将来厄介なバグが発生する可能性があります。)
一方、@BeforeClass
各クラスのテストが実行される前に実行されます。たとえば、継承に基づいて構築されたテストのために、クラスが異なるテストの対象となる場合、static
初期化子はこのクラスを使用する最初のテストに対してのみ実行されます。これは、テスト オーダーに依存するものを作成したことを意味します。
2 つのオプションの意味上の違いは@Before
、テストに または コンストラクターを使用する場合よりも大きいことに注意してください。最後の議論として、注釈の記録的価値について考えてみてください。それはあなたの意図をより読みやすくします。
この規則の唯一の例外は、不変の定数です。これらは、コードを簡潔に保ち、コンパイル時の定数を尊重するために、宣言内で初期化する必要があります。ただし、値が変更可能な場合は、値static
をまったく使用しないでください。繰り返しますが、テストで変更された変更可能な値は、避けるべきテストに順序依存性をもたらします。
TL;DR: 使用してください@BeforeClass
!
静的初期化ブロックを使用するか、またはを使用するかを決定する際に考慮できるいくつかの考慮事項を次に示し@BeforeClass
ます。
@BeforeClass
の拮抗薬です@AfterClass
。そのため、後でクリーンアップが必要な初期化 (外部リソースを開くなど) を行う場合は、(セマンティックの観点から) 注釈付きのメソッドを使用することをお勧めします。@BeforeClass
チェックされた例外をスローする可能性のある複雑な初期化を行う場合は、キャッチして未チェックの例外にラップする必要がないため、を使用する方がはるかに快適です。private static final String VARIABLE
する場合は、静的初期化ブロックまたは静的メソッドを使用するしかありません。SO に関する関連記事があります: unit testing - What's the difference between using @BeforeClass and using instance or static variable in JUnit 4 Java?
両方の場合、static
選択肢final
は1つだけです。静的初期化子です。
コンパイラは、静的かどうかに関係なく、メソッド内から最終フィールドに書き込むことを防ぎます。
編集:OK、質問から「final」という単語を削除しました。その場合、ほとんど違いはありません。静的初期化子は1回実行されます。@BeforeClassメソッドも同様です。読みやすいと思う方を選んでください。
まったく同じ動作ではありません。 @BeforeClass
テストが実行されるたびに実行され、静的初期化子はクラスがロードされたときに 1 回だけ実行されます。テストランナーが同じクラスローダを使用している場合、 の場合@BeforeClass
、静的変数の初期化を再実行します。ここで何を達成したいかによって異なります。