Como escrever um teste unitário em JUnit 5 e xUnit.net: anotações, ciclo de vida e casos parametrizados lado a lado

Objetivo

Escrever um teste que um leitor do outro ecossistema reconheça de imediato: um comportamento por teste, preparação visível e casos repetidos expressos como dados.

Pré-requisitos

JUnit Jupiter (junit-jupiter no classpath de testes e junit-jupiter-params para testes parametrizados) ou xUnit.net (xunit mais um runner), num projeto cujo build já executa testes; familiaridade com o artigo desta wiki sobre a estrutura geral de um teste unitário.

Passos

1. Dê à classe o nome da unidade testada e ao método o nome do comportamento: OrderTotalTest.appliesDiscountAboveThreshold() em Java, OrderTotalTests.AppliesDiscountAboveThreshold() em C#.
2. Marque o teste: no JUnit, @Test de org.junit.jupiter.api; no xUnit, [Fact]. Por padrão, os dois frameworks instanciam a classe de teste novamente para cada método de teste: a documentação do JUnit descreve o ciclo de vida por método e a opção @TestInstance(Lifecycle.PER_CLASS), e a página do xUnit sobre contexto compartilhado afirma que o construtor é executado para cada teste individual.
3. Coloque a preparação por teste onde o framework a espera: no JUnit, métodos @BeforeEach e @AfterEach; no xUnit, o construtor e Dispose(), ou IAsyncLifetime quando a preparação é assíncrona. Mantenha o estado em campos de instância, não estáticos.
4. Compartilhe contexto caro de forma deliberada: no JUnit, @BeforeAll num método estático (não estático no ciclo de vida por classe); no xUnit, IClassFixture<T> para uma instância de fixture por classe de teste e ICollectionFixture<T> entre classes, ambas criadas antes do primeiro teste e descartadas após o último.
5. Transforme testes copiados e colados em dados: no JUnit, @ParameterizedTest com @ValueSource, @CsvSource ou @MethodSource (a documentação exige pelo menos uma fonte); no xUnit, [Theory] com [InlineData(...)], [MemberData] ou [ClassData].
6. Verifique um único comportamento: no JUnit, assertEquals(expected, actual), assertThrows(Type.class, () -> ...) e assertAll(...) para agrupar asserções relacionadas; no xUnit, Assert.Equal(expected, actual) e Assert.Throws<T>(() => ...). Em ambos, o valor esperado vem primeiro.
7. Execute um teste pela linha de comando para comprovar a configuração: ./gradlew test --tests OrderTotalTest ou ./mvnw -Dtest=OrderTotalTest test; dotnet test --filter FullyQualifiedName~OrderTotalTests.

Resultado esperado

Cada arquivo de teste se lê da mesma forma nas duas linguagens: construção, ação, asserção. Tabelas de parâmetros substituem métodos duplicados, e o custo da preparação fica visível no gancho de ciclo de vida que o carrega.

Limites e base de verificação

Bibliotecas de asserção (AssertJ, Hamcrest, FluentAssertions, Shouldly) mudam a sintaxe do passo 6, não a estrutura. A execução paralela difere entre os frameworks e deve ser conferida na documentação deles antes de os testes compartilharem estado estático. O procedimento segue a documentação citada; não se afirma nenhuma comparação de velocidade ou de taxa de defeitos.