私の問題は、アノテーションを使用すると、テストが実行される前に、インスタンス化されたテストクラスにフィクスチャデータを渡す方法がわからないことです。
JUnit4スタイルのテストスイートは、JUnit3スタイルのテストスイートよりも制限されていることが知られています。これについての苦情を聞いたことがありますが、公式の解決策を知りません。この問題に取り組むサードパーティのソリューションがあるかもしれないと思います。特定の問題に関しては、JUnit4はメソッドが実行される直前にテストをインスタンス化するため、JUnit4スタイルのスイートからテストインスタンスにアクセスできるとは思いません。
最も簡単な方法は、JUnit3スタイルのスイートを引き続き使用することです。JUnit4で正常に動作するはずです。スイートを使用して共有リソースを管理することの欠点の1つは、テストクラスを個別に実行できなくなることです。一方、テストクラスをとにかく（おそらく特定の順序で）一緒に実行する必要がある場合は、それが有効な解決策になる可能性があります。
別のアプローチは、共有リソースの問題に裏返しに取り組むことです。あなたの場合、テストクラスは@Ruleを使用して、サーバーが存在する必要があることを宣言します。ルールが最初に実行されると、サーバーが起動し、関連情報が静的フィールドに保持され、テストの準備に必要なすべての処理が実行されます。たとえば、テストのフィールドの一部を挿入したり、テストでルールのAPIを使用して必要な情報を取得したりすることができます。次にルールが実行されると、「サーバーの開始」ステップがスキップされます。はい、静的状態は悪ですが、JUnitの制限を回避する唯一の方法である場合があります。（ここでは、他のテストフレームワークの使用については触れません。）
インサイドアウトアプローチの大きな利点は、テストクラスを直接（スイートを経由せずに）実行し、互いに独立して実行できることです。欠点は、実装がより困難になる可能性があることと、メモリ以外のリソースを破棄することが困難になることです（この場合：サーバーをシャットダウンします）。後者を実行するには、JUnitが適切なコールバックを提供しないため、JVMシャットダウンフックを使用する必要があります。これはおそらく機能しますが（ビルドツールとIDEは通常、テストの実行ごとに個別のJVMを使用するため）、それでも醜いです。
3番目のアプローチは、テストの実行前/実行後に、Ant / Maven/Gradle/その他のビルドをセットアップ/共通リソースを破棄することです。繰り返しになりますが、これは裏返しのアプローチよりも柔軟性と利便性が低く、ビルドからテストを実行しているJVMに情報を渡す方法（必要な場合）の問題が発生します。Maven Cargoプラグインは、このアプローチの典型的な例です。
最後になりましたが、実用的で、テストクラスごとに1回サーバーを起動/停止することができます。これは実装が非常に簡単ですが、状況に応じて適切な場合とそうでない場合があります（たとえば、時間がかかりすぎる場合があります）。
私は新しい@RuleとMethodRuleの手法を調べましたが、（率直に言って）それらは複雑であるように見えますが、実際には明確ではない問題に対する限定的な解決策です。
ルールは、モジュール式で再利用可能なJUnit拡張機能を作成する方法です。基本クラスを使用するよりもはるかに優れています。基本クラスでは、すぐに単一継承の問題が発生します。これは、JUnit拡張機能を出荷するライブラリーにさらに関係があります。
追加の懸念は、JUnitの作成者が最終的に@ Before /@Afterの概念をJUnitから削除することを意図しているように見えることです。
どこで聞いたの？これをxUnit.netと混同していませんか？xUnit.netは、セットアップ/ティアダウンメソッドの使用を強く推奨していませんか？とにかく、テストの前後に何らかのアクションを実行することは、ルールの最も重要なユースケースの1つなので、心配する必要はないと思います。