Écrire un test unitaire en JUnit 5 et xUnit.net : annotations, cycle de vie et cas paramétrés côte à côte

Objectif

Écrire un test qu'une personne venant de l'autre écosystème reconnaît immédiatement : un comportement par test, une initialisation visible, des cas répétés exprimés comme des données.

Prérequis

JUnit Jupiter (junit-jupiter sur le classpath de test, junit-jupiter-params pour les tests paramétrés) ou xUnit.net (xunit plus un runner) dans un projet dont la build exécute déjà des tests ; familiarité avec l'article général sur la structure des tests unitaires de ce wiki.

Étapes

1. Nommer la classe d'après l'unité et la méthode d'après le comportement : OrderTotalTest.appliesDiscountAboveThreshold() en Java, OrderTotalTests.AppliesDiscountAboveThreshold() en C#.
2. Marquer le test : JUnit @Test de org.junit.jupiter.api ; xUnit [Fact]. Les deux frameworks instancient la classe de test à neuf pour chaque méthode de test par défaut : la documentation de JUnit décrit le cycle de vie par méthode et le commutateur @TestInstance(Lifecycle.PER_CLASS), et la page de contexte partagé de xUnit indique que le constructeur s'exécute pour chaque test individuel.
3. Placer l'initialisation par test là où le framework l'attend : méthodes JUnit @BeforeEach et @AfterEach ; xUnit le constructeur et Dispose(), ou IAsyncLifetime quand l'initialisation est asynchrone. Garder l'état dans des champs d'instance, pas statiques.
4. Partager un contexte coûteux délibérément : JUnit @BeforeAll sur une méthode statique (non statique sous le cycle de vie par classe) ; xUnit IClassFixture<T> pour une instance de fixture par classe de test et ICollectionFixture<T> entre classes, toutes deux créées avant le premier test et disposées après le dernier.
5. Transformer des tests copiés-collés en données : JUnit @ParameterizedTest avec @ValueSource, @CsvSource ou @MethodSource (la documentation exige au moins une source) ; xUnit [Theory] avec [InlineData(...)], [MemberData] ou [ClassData].
6. Vérifier un seul comportement : JUnit assertEquals(expected, actual), assertThrows(Type.class, () -> ...), assertAll(...) pour regrouper des assertions liées ; xUnit Assert.Equal(expected, actual), Assert.Throws<T>(() => ...). Les deux placent la valeur attendue en premier.
7. Exécuter un test depuis la ligne de commande pour prouver le câblage : ./gradlew test --tests OrderTotalTest ou ./mvnw -Dtest=OrderTotalTest test ; dotnet test --filter FullyQualifiedName~OrderTotalTests.

Résultat attendu

Chaque fichier de test se lit de la même façon dans les deux langages : construction, action, assertion ; des tables de paramètres remplacent des méthodes dupliquées ; le coût de l'initialisation est visible dans le hook de cycle de vie qui le porte.

Limites et base de vérification

Les bibliothèques d'assertions (AssertJ, Hamcrest, FluentAssertions, Shouldly) changent la syntaxe de l'étape 6, pas la structure. L'exécution parallèle diffère entre les frameworks et doit être vérifiée dans leur documentation avant que des tests ne partagent un état statique. La procédure suit la documentation citée ; aucune comparaison de vitesse ou de taux de défauts n'est revendiquée.