Junit4: 非推奨のExpectedExceptionルール

非推奨の警告は、より良いものが利用可能であることを示す良い方法だと思います。そのため、正当な理由もなく警告は表示されません。 ExpectedExceptionは簡単に誤用される可能性がありますが、それでも多くの場所で推奨されています。

問題は、ユーザーがこれらの非推奨の警告を受け取ることがどれほど問題があるかということです。 私の会社では、非推奨の警告はビルド時に表示されません（コードを表示している場合のみ）。

サムはここにポイントがあると思います。 私はすべての（新しい）コンパイラ警告を禁止する多くのビルドを見てきました。 このようなプロジェクトでは、 ExpectedExceptionを使用するすべてのテストクラスを実行し、 SuppressWarningsアノテーションを追加する必要があります。

@stefanbirkner WDYT？

クライアントに警告を抑制させるのは合理的なようです。 また、すべての非推奨警告を抑制することもできます。 非推奨の警告をエラーとして扱うと、何も非推奨にすることができなくなります。

非推奨は、古いAPIに問題があり、はるかに優れたAPIが利用可能であることを人々に示すための最善の方法です。

開発者がIDE内でローカルに警告を抑制できることを理解しています。 ただし、JUnit 4.xの（予定されている）最終リリースでコア機能を廃止することは良い考えであることに同意しません。

私見ですが、フレームワークの最終リリース、特にJUnit 4のように広く使用されているフレームワークのコア機能を廃止することは、お勧めできません。

具体的な例として、コアSpring Frameworkテストスイートでは、 ExpectedExceptionルールの使用に関する数千の非推奨警告があります。

私たちが持っている唯一のオプションは次のとおりです。

1. ExpectedExceptionを使用するすべてのテストクラスで非推奨の警告を抑制します。
2. ExpectedExceptionを使用するすべてのテストクラスでの使用から移行します。
3. 何もしない。

＃1を使用すると、クラスレベルで警告を抑制するスクリプトを使用してそれを実現できる可能性がありますが、それにより、知っておく必要があり、無視しない可能性のある他のAPIの非推奨警告が抑制されます。 それ以外の場合は、各テストクラスを手動で実行し、 ExpectedException APIの使用を非推奨にする必要があります。これには、影響を受けるすべてのテストメソッドでのルールインスタンスとのすべての単一の相互作用が含まれます。

＃2を使用する場合、これは手動で実行するのに数日かかる可能性のある主要な作業です。 部分的な自動化は可能かもしれませんが、自動化（スクリプトなど）への投資はそれ自体でかなり広範囲に及ぶ可能性があります。

＃3を使用すると、（私たちの観点から）不要な非推奨警告が発生し、実際に気になる非推奨警告のビューが曇ってしまい、ウィンドウが

＃2を実行すると、JUnit5への将来の移行が簡素化されます。

＃2を実行すると、JUnit5への将来の移行が簡素化されます。

もちろん。 これにより、JUnitJupiterまたはAssertJへの移行が簡単になる可能性があります。 ただし、すべての人が既存のテストスイートを移行したい、または移行する必要があるわけではありません。

したがって、私はそれを有効な議論とは見なしません。

これが最後のJUnit4.xリリースである可能性が高いのは、私たちが物事を非推奨にするかどうかに関係している理由がわかりません。 JUnitが_any_APIを削除することはめったにないため、非推奨はAPIがなくなることを示すものではありません。 これは、APIがサポートされていないか、より優れたAPIが存在する可能性があることを示しています。 この場合、両方とも当てはまります（ assertThrows()使用する方がよいと考えたため、このルールに対する提案された変更を拒否しました）

SpringはExpectedExceptionからゆっくりと移行することをお勧めします。 より安全で理解しやすいテストに到達するために、数日間の作業が数か月に渡って行われたことは、勝利のように思えます。 利点は、JUnitの最近の変更にあまり詳しくない他の人が、 ExpectedExceptionを回避することを知っていることです。

ErrorProneには、推奨される修正を提供するあります。したがって、この問題を解決するのに数日かかるとは思いません。

TL; DRExpectedExceptionの非推奨に賛成です。

@kcooneyは、JUnit 4の設計上の決定は変更の

例外をチェックするより良い方法があることを人々に伝えるので、非推奨にすることは有益だと思います。 私は過去10年間、いくつかの会社で働いていましたが、 @Test(expected=ABeautifulException.classよりも優れたものがあることに驚いている人が常にいます。 非推奨は、IDEでストライキされたコードを見ると通常見られるため、彼らにとって価値があります。

これらの警告を修正する必要がないため、非推奨の警告は煩わしい場合があります。 これの起源は、JUnit4が非推奨を使用する方法です。 したがって、ExpectedExceptionを非推奨にしない（そして最終的には非推奨をまったく使用しない）ことを除けば、これに対する修正はないと思います。

最後になりましたが、非推奨の警告が発生した場合にビルドが壊れて、JUnit4.13に簡単にアップグレードできない企業があります。 これらの企業がどれだけ存在するかはわかりません。これらの企業は、a）このビルドポリシーを持っており、b）JUnit4.13にアップグレードしたいと考えています。

@sdeleuze、@ mp911deとあなたが廃止を元に戻すに投票@rweisleder。 非推奨にしない理由を教えていただければ助かります。

もう少し詳しく説明すると、Spring FrameworkのコードベースをJUnitのExpectedExceptionからAssertJのassertThatExceptionOfTypeに移行するのに約1。5日かかりました。

役立つかもしれない小さな提案の1つは、クラス全体ではなく、 ExpectedException.none()メソッドのみを非推奨にすることを検討することです。 これは依然として人々に警告を与えますが、それは単独で抑制することをはるかに容易にします。

JUnitのExpectedExceptionは、 @Test(expected = …)だけでなく、より広範な例外アサーションを実行するテストのプリミティブ型として使用されます。 これらは通常、Hamcrestまたは組み込みのアサーションに依存するテストであり、AssertJなどにはあまり依存しません。

JUnit 4.13を使用していることは、アクティブなメンテナンスが行われていることを示しています。 JUnit 4.x APIに残っているコードベースは、すぐにJUnit 5 APIに移行されない可能性がありますが、ヴィンテージエンジンに移行する可能性のあるAPIを維持します。 突然非推奨になったクラスがあると、新しい警告が生成され、コードはまだ機能している可能性がありますが、別のアサーションユーティリティに移行するための追加の作業が発生しました。

非推奨と改善されたAPIの導入を数回観察しました。 ほとんどの場合、非推奨は実際のユーザーではなくメンテナに役立ちました。 ユーザー側では、これはほとんどの努力を生み出しましたが、利益はありませんでした。

役立つかもしれない小さな提案の1つは、クラス全体ではなく、 ExpectedException.none()メソッドのみを非推奨にすることを検討することです。 これは依然として人々に警告を与えますが、それは単独で抑制することをはるかに容易にします。

JUnit 4チームがExpectedExceptionルールの廃止を取り消さないことを決定した場合、これは適切な妥協案になると思います。

私はかしら@Test(expected = ...)我々は持っているので、また、廃止されるべきでassertThrows今すぐ。 または、少なくともExpectedExceptionへの参照を属性のJavadocから削除する必要があります。

私はかしら@Test(expected = ...)我々は持っているので、また、廃止されるべきでassertThrows今すぐ。 または、少なくともExpectedExceptionへの参照を属性のJavadocから削除する必要があります。

はい、 expectedで属性org.junit.Testおそらく廃止されるべきです。 いずれの場合も、 org.junit.Testおよびexpected属性のクラスレベルのJavadocを更新して、 assertThrows使用を推奨する必要があります。

ExpectedException.none()だけを非推奨にすることに賛成です。

非推奨を使用して新機能をアドバタイズすることは、JUnit開発プロセスへの信頼を損ない、バージョン4.13の採用を妨げるような手間のかかるアプローチだと思います。

古い機能と新しい機能が非推奨になることなく共存する場合は、バージョンが重複するはずです。 他の人が指摘しているように、非推奨のメソッドに依存することは、コードの品質を高く保つ多くのプロジェクトにとっては無駄です。 つまり、JUnitのアップグレードは、コードベース全体を移行するための変更と同じコミットで行う必要があります。

機能が非推奨になり、同じリリースで置換が追加される唯一の状況は、機能が根本的に壊れており、すぐに移行する必要がある場合だと思います。 ExpectedExceptionが根本的に壊れているとは思いません。

新しい依存関係をチェックして、どのような変更が行われるのか、コードをどのように準備できるのかを確認することがよくありました。 では、JUnit 4.13の移行に向けてコードを準備するにはどうすればよいですか？ ExpectedExceptionが非推奨になることは知っていますが、まだ適切な代替品がありません。 その混乱を完全に回避するために、例外をキャッチしてチェックするために独自のコードを実装する必要があります。

4.13が最終的な4.xリリースになる予定であるという理由だけで、まともなソフトウェア開発慣行を放棄するのは良い理由ではありません。 実際、4.13はExpectedException非推奨なしでリリースでき、4.14は非推奨の翌日リリースできます。 それは、開発者に過度のプレッシャーなしに移行を行うための少しの息抜きを与えながら、メッセージを伝えるでしょう。

古い機能と新しい機能が非推奨になることなく共存する場合は、バージョンが重複するはずです。

どうして？ 非推奨の目的は、私たちの意見では、より良いAPIである新しいことを人々に認識させることです。

また、侵襲性を低くするためにExpectedException.none()のみを非推奨にする必要があることにも同意します。

@stefanbirknerよろしいですか？

@marcphilippコードを更新するとき、何か間違ったことをしていない限り、非推奨になることなく動作させたいと思っています。 機能を廃止すると同時に代替品を提供するには、煩わしすぎます。 代わりに、4.13リリースノートには、 ExpectedExceptionが次のバージョンで非推奨になると記載されており、置き換えを提案する必要があります。 そうすれば、その間に非推奨を許可することなく、コードを段階的に移行する方法があります。 これは、JUnit 4.12を何年も使用していて、大きな変更を望まないユーザーへの基本的な礼儀です。

非推奨の警告のポイントは、コードを置換に向けて移行する時間を与えるためのものです。 非推奨の警告を回避する必要がある場合は、 ExpectedException.none()委任する独自の一時ファクトリメソッドを作成できます。

OK、PRは問題をある程度軽減します、それは間違いなく正しい方向への一歩です。 それをしてくれてありがとう！

ユーザーがファクトリメソッドを実装することを提案するのではなく、コードは独自の非推奨でないメソッドを提供することができます（おそらくnoneに追加の引数があります）。

ユーザーに移行バージョンを提供することに対する抵抗をまだ理解していません。 互換性のない変更を実装する場合、強制せずに移行できるバージョンを作成することは非常に一般的です。

移行バージョンがない場合、ユーザーは4.13を試し、大量の警告を確認して、4.12に戻ります。

移行バージョンでは、ユーザーは4.14を試し、大量の警告を表示し、4.13を試し、警告を表示せず、それを使用します。 すぐに4.14に更新するものもあれば、更新する正当な理由がない限り、4.13をそのまま使用するものもあります。 どちらにしても問題ないはずです。

また、この非推奨がJUnit 4で発生した理由もわかりません。両方のバージョンを一時的にサポートするために、 junit-vintage-engineを使用してJUnit5に移行しています。 しかし、これはJUnit 4.13を引き込みます。これは、何らかの理由で、最後のリリースの1つである可能性が高いもの（長年サポートされてきたもの）を非推奨にすることをお勧めします。

また、代替案を指摘する以外に非推奨の理由はないようです。これは、少なくとも代替案を提供することで達成できた可能性があります（コンストラクターを公開するか、別の静的メソッドを提供します-メッセージ通信）。

ExpectedExceptionコードは、（当時）便利な方法で提供されたJUnitの基本機能を使用するだけなので、現在も機能し続けます（そして、今後のリリースでも機能し続けます）。

例外に関するプロパティをアサートするための代替手段は何ですか...

古いコード：

thrown.expect(StatusRuntimeException.class);
thrown.expect(its(StatusRuntimeException::getStatus, toBe(Status.INVALID_ARGUMENT)));
GrpcDispatch.makeRequest(service::enableJob, JobReference.newBuilder().setName(UNKNOWN_JOB).build());

assertThrowsには、予期された例外を完全に非推奨にするためのマッチャーバージョンがないようです。手遅れだとわかっていますが、他の誰もこの問題を抱えていませんか？

@daicoden

assertThrowsがスロー可能オブジェクトを返すと確信しているので、他のオブジェクトの場合と同じように、それをキャプチャしてアサーションを作成できます。

StatusRuntimeException thrown = assertThrows(StatusRuntimeException.class, () -> {
   GrpcDispatch.makeRequest(service::enableJob, JobReference.newBuilder().setName(UNKNOWN_JOB).build());
});

assertEquals(Status.INVALID_ARGUMENT, thrown.getStatus());