この表から解るように、一部の機能を除けばJUnit4の機能は継承されています。 したがって、JUnit4を理解していれば継承された機能をJUnit5に移行することは難しくないでしょう。 最初は多少の混乱はあるかと思いますが、すぐに慣れるレベルかと思います。 逆に、新しくJUnit5からJavaのユニットテストに入るのであれば、JUnit4の制約がないことは良い材料です。 特に、構造化テスト（ネストクラス）の時、JUnit4ではネストクラスをstaticクラスにすることを強いられていました。 これは、テストクラスをテスト毎に作成するという制約があったためです。 この制約がある以上、テストクラスからアウタークラスのインスタンス変数にアクセスできませんでした。 ユニットテストではテスト毎にテストインスタンスを作成することが原則なので、この制約は仕方ないと考えても良いでしょう。 しかし、テストがネ

Java にはリフレクションがあり、当時は目新しかった。 人々がリフレクション API を使いこなしだすと遅さが目立ち始めた。ライブラリ開発者はリフレクションを実行時バイトコード生成で置き換えた。こうして Java のバイトコード編集ライブラリが発達した。 言語仕様にアノテーションが追加されたのも同じ頃。アノテーションと実行時バイトコード生成が Java フレームワークのデザインに与えた影響は大きく、モダンなサーバサイド Java は案外簡潔なコードを書けたりする。XML がアノテーションになっただけ、とは言わない約束。いちおう型をチェックできるし、冗長といわれる Java だって XML よりは簡潔だし。 Android Java は実行時に Java バイトコードを解釈できない。だから Java のコード生成資産が使えない。実行時にロードできる DEX にもデータを一旦ファイルに書かな