Escribir una prueba unitaria en JUnit 5 y xUnit.net: anotaciones, ciclo de vida y casos parametrizados en paralelo

Objetivo

Escribir una prueba que alguien procedente del otro ecosistema reconozca de inmediato: un comportamiento por prueba, la configuración visible, los casos repetidos expresados como datos.

Requisitos previos

JUnit Jupiter (junit-jupiter en el classpath de pruebas, junit-jupiter-params para las pruebas parametrizadas) o xUnit.net (xunit más un runner) en un proyecto cuya build ya ejecute pruebas; familiaridad con el artículo general sobre la estructura de las pruebas unitarias en este wiki.

Pasos

1. Nombrar la clase según la unidad y el método según el comportamiento: OrderTotalTest.appliesDiscountAboveThreshold() en Java, OrderTotalTests.AppliesDiscountAboveThreshold() en C#.
2. Marcar la prueba: @Test de org.junit.jupiter.api en JUnit; [Fact] en xUnit. Ambos frameworks instancian la clase de prueba de nuevo para cada método de prueba de forma predeterminada: la documentación de JUnit describe el ciclo de vida por método y el modificador @TestInstance(Lifecycle.PER_CLASS), y la página de contexto compartido de xUnit indica que el constructor se ejecuta para cada prueba individual.
3. Colocar la configuración por prueba donde el framework la espera: los métodos @BeforeEach y @AfterEach en JUnit; el constructor y Dispose() en xUnit, o IAsyncLifetime cuando la configuración es asíncrona. Mantener el estado en campos de instancia, no en estáticos.
4. Compartir el contexto costoso de forma deliberada: @BeforeAll sobre un método estático en JUnit (no estático bajo el ciclo de vida por clase); IClassFixture<T> en xUnit para una instancia de fixture por clase de prueba, y ICollectionFixture<T> entre clases, ambos creados antes de la primera prueba y liberados después de la última.
5. Convertir en datos las pruebas copiadas y pegadas: @ParameterizedTest con @ValueSource, @CsvSource o @MethodSource en JUnit (la documentación exige al menos una fuente); [Theory] con [InlineData(...)], [MemberData] o [ClassData] en xUnit.
6. Comprobar un solo comportamiento: assertEquals(expected, actual), assertThrows(Type.class, () -> ...), assertAll(...) para agrupar aserciones relacionadas en JUnit; Assert.Equal(expected, actual), Assert.Throws<T>(() => ...) en xUnit. Ambos colocan primero el valor esperado.
7. Ejecutar una prueba desde la línea de comandos para comprobar que todo está conectado: ./gradlew test --tests OrderTotalTest o ./mvnw -Dtest=OrderTotalTest test; dotnet test --filter FullyQualifiedName~OrderTotalTests.

Resultado esperado

Cada archivo de prueba se lee de la misma forma en ambos lenguajes: construcción, acción, aserción; las tablas de parámetros sustituyen a los métodos duplicados; el coste de la configuración es visible en el hook del ciclo de vida que lo transporta.

Límites y base de verificación

Las bibliotecas de aserciones (AssertJ, Hamcrest, FluentAssertions, Shouldly) cambian la sintaxis del paso 6, no la estructura. La ejecución en paralelo difiere entre los frameworks y debe comprobarse en su documentación antes de que las pruebas compartan estado estático. El procedimiento sigue la documentación citada; no se afirma ninguna comparación de velocidad ni de tasas de defectos.