JUnit 5 と xUnit.net で単体テストを書く：注釈、ライフサイクル、パラメーター化ケースの比較

目的

別のエコシステムの読み手がすぐ理解できるテストを書く。テストごとに一つの振る舞いを扱い、準備を見える形にし、繰り返すケースはデータで表す。

前提条件

ビルドでテストを実行できるプロジェクトに、JUnit Jupiter（テストのクラスパスに junit-jupiter、パラメーター化テスト用に junit-jupiter-params）または xUnit.net（xunit とランナー）があること。この Wiki の単体テストの基本構造の記事を理解していること。

手順

1. クラスは対象の単位に、メソッドは振る舞いにちなんで命名する。Java なら OrderTotalTest.appliesDiscountAboveThreshold()、C# なら OrderTotalTests.AppliesDiscountAboveThreshold() とする。
2. テストを示す。JUnit は org.junit.jupiter.api の @Test、xUnit は [Fact] を使う。両フレームワークとも、既定ではテストメソッドごとにテストクラスのインスタンスを作り直す。JUnit の文書はメソッドごとのライフサイクルと @TestInstance(Lifecycle.PER_CLASS) による切り替えを説明し、xUnit の共有コンテキストのページは、すべてのテストでコンストラクターが実行されると述べている。
3. テストごとの準備と後始末を、フレームワークの想定する場所に置く。JUnit は @BeforeEach と @AfterEach のメソッド、xUnit はコンストラクターと Dispose() を使い、非同期の準備には IAsyncLifetime を使う。状態は静的フィールドではなくインスタンスフィールドに保持する。
4. 高コストのコンテキストは意図して共有する。JUnit は静的メソッドの @BeforeAll（クラスごとのライフサイクルでは非静的）、xUnit はテストクラスごとに一つのフィクスチャを持つ IClassFixture<T> と、クラス間で共有する ICollectionFixture<T> を使う。両フィクスチャとも最初のテストの前に作成し、最後のテストの後に破棄する。
5. コピーしたテストをデータに変える。JUnit は @ParameterizedTest に @ValueSource、@CsvSource、@MethodSource のいずれかを組み合わせる（文書では少なくとも一つのソースが必須）。xUnit は [Theory] と [InlineData(...)]、[MemberData]、[ClassData] のいずれかを使う。
6. 一つの振る舞いを検証する。JUnit は assertEquals(expected, actual)、assertThrows(Type.class, () -> ...) を使い、関連する検証は assertAll(...) でまとめる。xUnit は Assert.Equal(expected, actual)、Assert.Throws<T>(() => ...) を使う。どちらも期待値を先に置く。
7. コマンドラインから一つのテストを実行して、接続ができていることを確認する。./gradlew test --tests OrderTotalTest または ./mvnw -Dtest=OrderTotalTest test、そして dotnet test --filter FullyQualifiedName~OrderTotalTests を使う。

期待される結果

どちらの言語でも、各テストファイルが構築、操作、検証という同じ順で読める。重複したメソッドがパラメーター表に置き換わり、準備のコストがそれを担うライフサイクルフックに表れる。

限界と検証の根拠

アサーションライブラリ（AssertJ、Hamcrest、FluentAssertions、Shouldly）が変えるのは手順 6 の構文であり、構造ではない。並列実行はフレームワーク間で異なるため、テストで静的状態を共有する前に、それぞれの文書で確認しなければならない。この手順は引用した文書に従っており、速度や欠陥率の比較を行ったとは主張しない。