Про базовые сведения о JUnit 5 было освещено в прошлом разделе, инструкция по подключению находится там же.
[Ссылка]

Assertions позволяют сравнить ожидаемые значения с фактическими.

assertEquals() и assertNotEquals() помогают убедиться в том, что фактическое значение идентично с ожидаемым и наоборот.

Пример:
В этом примере мы ожидаем получить строку Good и ее же получаем. Поэтому тест пройдет.

Assertions.assertEquals("Good", "Good");

Если заменить один из входных параметров, то тест упадет.

Assertions.assertEquals("Good", "Bad");
// Ожидали Good, а получили Bad. Тест упал.

Если утверждение в скобках верно, то тест пройдет.

Assertions.assertTrue(5 > 2);
// 5 на самом деле больше 2 и тест пройдет

Если утверждение в скобка ложно, то тест пройдет.

Assertions.assertFalse(10 < 2);
// 10 не меньше 2, значит тест тоже пройдет

Позволяет проверить сразу несколько утверждений. Даже если одно из них упадет, то все равно будут выполнены все до самого конца, а система покажет те, которые упали.

Пример:

Assertions.assertAll(
   () -> Assertions.assertFalse(10 < 2),
   () -> Assertions.assertTrue(5 > 2),
   () -> Assertions.assertEquals("Good", "Good")
);

Позволяет дать лаконичное и понятное название для теста или класса. Важно заметить, что строка аннотации не печатается в консоли, а отображается в IDE и смежных инструментах, поддерживающих интеграцию.

Пример:

@DisplayName("Тест главной страницы")

Если какой-то тест падает из-за ошибки со стороны разработчиков или его просто пока надо отключить, то не следует комментировать все тело теста. Для этих целей предусмотрена аннотации @Disabled. Стоит ставить ее перед тем тестом, который необходимо отключить. В виде строки можно передать причину отключения. Можно скрыть не только один тест, но и все тесты в классе. Для этого аннотации надо указать перед классом.

Пример:

@Disabled("Ужас! Все падает!")
@DisplayName("Тест главной страницы")
@Test
void mainPageTets() {
    // Тело теста
}

Тест-кейс — это профессиональная документация тестировщика, последовательность действий направленная на проверку какого-либо функционала, описывающая как прийти к фактическому результату. Набор тест-кейсов называют тест-комплектом.

Что должно быть в тест-кейсе:

• Уникальный номер — помогает в больших проект организовано содержать базу тест-кейсов;
• Заголовок — описывает основную идея теста;
• Предусловия — описывает условия, которые не имеют прямого отношения к тест-кейсу, но все равно должны быть выполнены;
• Шаги — последовательность действий теста;
• Ожидаемый результат — результат, то, что мы ожидаем увидеть после выполнения теста.

Пример:

Заголовок: Проверка поиска в Яндексе по слову "Тестирование ПО"

Предусловия: открыть браузер со страницей ya.ru

Шаги:
- Ввести фразу "Тестирование ПО"
- Нажать кнопку "Найти"

Ожидаемый результат:
- Открылась страница результатов, содержащая карточку с текстом "Тестирование ПО"

Чего не должно быть в тест-кейсах:

• Расплывчатых формулировок шагов;
• Излишних деталей (не надо описывать каждый микрошаг);
• Зависимостей от других тест-кейсов.

Во время тестирования бывает так, что код надо проверить несколько раз, но с разными входными данными. В JUnit5 есть механизм, позволяющий отделить код теста от данных теста и запускать тест несколько раз.

@ParameterizedTest Чтобы выполнить тест несколько раз, но с разными аргументами, следует использовать аннотацию @ParameterizedTest. При этом нам нужен поставщик данных для теста. Для этого можно использовать аннотацию @ValueSource().

Пример: Наш тест надо запустить дважды и каждый раз для тестирования нужна новая входная строка. Сделать это можно следующим образом.

@ValueSource(strings = {
    "Google",
    "Yandex"
})
@ParameterizedTest
void SearchTest (String testData) {
    // тело теста
}

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

Пример:
Нам надо проверить имя и возраст людей из анкеты. Для этого нужен параметр имени и возраста.

@CsvSource(value = {
    "alex, 30",
    "brian, 35",
    "charles, 40"
})
void TestWithCsvSource (String name, int age) {
    // тело теста
}

Если нам надо передавать в виде аргументов сложные данные, то мы можем использовать собственный метод передачи данных и аннотацию @MethodSource.

Пример:

// Метод передачи данных. Его имя должно совпадать с именем аннотации ниже
static Stream<Arguments> methodSourceExampleTest() {
        return Stream.of(
                // с первым запуском тест получит в виде аргументов строки и список
                Arguments.of("first string", List.of(42, 13)),
                // со вторым запуском уже другую строку и список
                Arguments.of("second string", List.of(1, 2))
        );
    }

    // Аннотация поставщика данных, помним про имя
    @MethodSource("methodSourceExampleTest")
    @ParameterizedTest
    // Метод теста. В этом случае просто выводит в консоль аргументы
    void methodSourceExampleTest(String first, List<Integer> second) {
        System.out.println(first + " and list: " + second);
    }

@EnumSource позволяет хранить Enum-константы — конечное количество тестовых данных.

Пример:
Наш тест связан со сторонами света, а их всего 4 и в любое время года их всегда будет 4.

enum Direction {
    EAST, WEST, NORTH, SOUTH
}

@ParameterizedTest
@EnumSource(Direction.class)
void testWithEnumSource(Direction d) {
    // тело теста
}