В этом примере JUnit 5 мы делаем следующее:

  1. Мы инициализируем экземпляр класса Calculator, функциональность которого мы тестируем (1’).
  2. Мы утверждаем, что выполнение предоставленного исполняемого файла calculator.sqrt(-1) вызывает IllegalArgumentException (2’).
  3. Мы утверждаем, что выполнение предоставленного исполняемого файла calculator.divide(1, 0) вызывает ArithmeticException (3’).

Мы отмечаем явную разницу в ясности кода и длине кода между JUnit 4 и JUnit 5. Эффективный тестовый код JUnit 5 составляет 13 строк, эффективный код JUnit 4 — двадцать строк. Нам не нужно инициализировать и управлять каким-либо дополнительным правилом. Методы тестирования JUnit 5 содержат по одной строке каждый.

Еще одно правило, которое мы хотели бы перенести, — TemporaryFolder. Правило TemporaryFolder позволяет создавать файлы и папки, которые должны быть удалены после завершения метода тестирования (независимо от того, пройден он или нет). Правило JUnit 4 было заменено аннотацией @TempDir в JUnit 5. В листинге 4 представлен подход JUnit 4.

В этом примере мы делаем следующее:

  1. Мы объявляем поле TemporaryFolder с аннотацией @Rule и инициализируем его. Аннотация @Rule должна применяться либо к общедоступному полю, либо к общедоступному методу (1).
  2. Мы используем поле TemporaryFolder для создания папки и файла (2). Их можно найти в папке Temp вашего профиля пользователя в операционной системе.
  3. Проверяем наличие временной папки и временного файла (3).

Теперь перейдем к новому подходу JUnit 5 (листинг 5).

В предыдущем примере JUnit 5 мы делаем следующее:

  1. Мы объявляем аннотированное поле @TempDir (1’).
  2. Мы проверяем создание этого временного каталога перед выполнением теста (2’).
  3. Мы создаем файл в этом каталоге и проверяем его существование (3’).

Преимущество подхода расширения JUnit 5 заключается в том, что нам не нужно создавать папку самостоятельно с помощью конструктора, но папка создается автоматически, как только мы аннотируем поле с помощью @TempDir.

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

В JUnit 4 нам нужно было, чтобы наши дополнительные действия выполнялись до и после выполнения теста. Следовательно, мы можем создавать собственные классы, реализующие интерфейс TestRule. Для этого необходимо переопределить метод apply(Statement, Description), который возвращает экземпляр Statement. Такой объект представляет тесты в среде выполнения JUnit и Statement#evaluate() их запускает. Объект Описание описывает отдельный тест. Мы можем использовать его для чтения информации о тесте посредством отражения.

Чтобы наглядно показать, как определять наши собственные правила, мы смотрим на листинг 6, где мы делаем следующее:

  1. Мы объявляем наш класс CustomRule, реализующий интерфейс TestRule (1).
  2. Мы сохраняем ссылки на поле Statement и поле Description (2) и используем их в методе apply, который возвращает CustomStatement (3).

Заинтересованы в Java? Посетите наши тренинги.

Каталин Тудоуз
Эксперт по Java и веб-технологиям

Первоначально опубликовано на https://www.luxoft-training.com.