Модульный тест в JUnit 5 и xUnit.net: сравнение аннотаций, жизненного цикла и параметризованных случаев

Цель

Написать тест, который читатель из другой экосистемы сразу узнает: одно поведение на тест, явная подготовка, повторяющиеся случаи в виде данных.

Предварительные условия

JUnit Jupiter (junit-jupiter в пути классов тестов, junit-jupiter-params для параметризованных тестов) или xUnit.net (xunit вместе с исполнителем) в проекте, сборка которого уже запускает тесты; знакомство со статьёй об общей структуре модульного теста в этой вики.

Шаги

1. Назовите класс по тестируемому модулю, а метод — по поведению: OrderTotalTest.appliesDiscountAboveThreshold() в Java, OrderTotalTests.AppliesDiscountAboveThreshold() в C#.
2. Отметьте тест: в JUnit — @Test из org.junit.jupiter.api; в 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, но не структуру. Параллельное выполнение у фреймворков различается, и прежде чем тесты начнут разделять статическое состояние, необходимо свериться с документацией. Процедура следует цитируемой документации; сравнение скорости или частоты дефектов не заявляется.