JUnit 5: основы

Жизненный цикл и почему он такой

Порядок из моего замера, полностью: BeforeAll один раз на весь класс, потом на КАЖДЫЙ тест - BeforeEach, сам тест, AfterEach, и в конце AfterAll. Между тестами создаётся новый объект класса, поэтому поля начинаются с чистого листа.

Отсюда ответ на вопрос «зачем @BeforeEach, если есть конструктор». Конструктор тоже вызывается перед каждым тестом, но в нём ещё не отработали расширения фреймворка: не внедрены зависимости, не подставлены моки. @BeforeEach выполняется позже и видит уже собранную обстановку.

// BeforeAll и AfterAll статические именно потому, что относятся ко всему классу, а не к экземпляру - экземпляров-то много. В них кладут дорогое и общее: поднять контейнер с базой, прочитать большой файл. Всё, что должно быть свежим у каждого теста, живёт в BeforeEach.

BeforeAll
  BeforeEach
    тест 2, counter=1
  AfterEach
  BeforeEach
    тест 1, counter=1
  AfterEach
AfterAll

разных экземпляров класса теста: 2

@BeforeEach / @BeforeAll

перед каждым тестом / один раз на класс, поэтому статический

изоляция

новый экземпляр на каждый тест, поля не переносятся

Проверки, которые стоит знать

Сравнение сложных значений работает по содержимому, и сообщение об ошибке само говорит, что не сошлось: у меня сравнение двух списков дало expected: <[1, 2, 3]> but was: <[1, 3, 2]>. Отсюда правило: сравнивай целые объекты, а не разбирай их по полям вручную - тогда провал сразу читаем.

Обычная цепочка проверок останавливается на первой неудаче, и ты видишь одну проблему из трёх. Проверка группой это меняет: в моём замере она выполнила обе проверки и выдала Multiple Failures (2 failures) с обоими сообщениями сразу. Удобно, когда проверяешь несколько полей одного результата.

Исключения проверяют не через try-catch с пометкой о провале, а специальной конструкцией: она выполняет код, требует, чтобы исключение вылетело, и ВОЗВРАЩАЕТ его. Дальше можно проверить сообщение и причину. Без возврата тест ловил бы сам факт исключения, но не его содержание.

var e = assertThrows(IllegalArgumentException.class,
                     () -> service.pay(-100));
assertEquals("сумма должна быть положительной", e.getMessage());

// сравнение списков при провале:
// expected: <[1, 2, 3]> but was: <[1, 3, 2]>

// группа проверок:
// Multiple Failures (2 failures) ... первая ... вторая

assertThrows

требует исключение и возвращает его для дальнейших проверок

assertAll

выполняет все проверки и показывает все провалы разом

Порядок, параметризация и общая обстановка

Мой замер показал, что тесты выполняются не в порядке объявления. Это сделано намеренно: порядок стабилен между запусками, но специально не совпадает с исходным кодом, чтобы никто не начал на него закладываться. Тест, который работает только после соседа, - сломанный тест.

Параметризованный тест избавляет от копирования: один метод, а данные приходят набором - списком значений, парами вход-ожидание или из файла. Вместо пяти почти одинаковых методов получается один и пять строк данных, причём в отчёте каждая строка видна отдельно.

// Расширения - способ вынести общую обстановку: поднять базу, подставить фиксированное время, подчистить за тестом. Своё расширение подключается аннотацией к классу и работает у всех тестов внутри, поэтому одинаковую подготовку не приходится копировать по проекту.

параметризованный тест

один метод, набор данных, каждая строка отдельно в отчёте

расширение

общая подготовка и уборка, подключаемая к классу теста

Как отвечать: «Как проверить, что метод бросает исключение?»

Специальной конструкцией assertThrows: передаю ожидаемый тип и код в виде лямбды. Она проверяет, что исключение действительно вылетело и что оно нужного типа, а главное - возвращает сам объект исключения. Дальше я проверяю сообщение и причину, потому что «упало хоть что-то» это слабая проверка: метод мог свалиться совсем по другому поводу и тест всё равно был бы зелёным. Ловить исключение вручную через try-catch я не стал бы: тогда легко забыть пометить провалом случай, когда исключения НЕ было, и тест начнёт молча проходить всегда. И ещё слежу, чтобы в лямбде была ровно одна операция, которая должна упасть, иначе непонятно, какая именно строчка бросила исключение.

Почему это сильный ответ: назван инструмент, объяснено, зачем нужен возвращаемый объект, и разобрана ошибка ручного try-catch, из-за которой тест перестаёт что-либо проверять.

На чём валят

• −Закладываться на порядок тестов. У меня второй тест выполнился раньше первого - порядок специально не совпадает с исходным кодом.
• −Переносить состояние между тестами через поле. На каждый тест создаётся новый экземпляр, поле обнулится - я это проверял счётчиком.
• −Ловить исключение вручную и забыть про случай, когда его не было. Тест станет зелёным навсегда.
• −Проверять только тип исключения. Метод мог упасть по другой причине, а тест этого не заметит.
• −Разбирать результат по полям вместо сравнения целиком. Сообщение о провале перестаёт объяснять, что именно разошлось.