В этом примере JUnit 5 мы делаем следующее:
- Мы инициализируем экземпляр класса Calculator, функциональность которого мы тестируем (1’).
- Мы утверждаем, что выполнение предоставленного исполняемого файла calculator.sqrt(-1) вызывает IllegalArgumentException (2’).
- Мы утверждаем, что выполнение предоставленного исполняемого файла 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.
В этом примере мы делаем следующее:
- Мы объявляем поле TemporaryFolder с аннотацией @Rule и инициализируем его. Аннотация @Rule должна применяться либо к общедоступному полю, либо к общедоступному методу (1).
- Мы используем поле TemporaryFolder для создания папки и файла (2). Их можно найти в папке Temp вашего профиля пользователя в операционной системе.
- Проверяем наличие временной папки и временного файла (3).
Теперь перейдем к новому подходу JUnit 5 (листинг 5).
В предыдущем примере JUnit 5 мы делаем следующее:
- Мы объявляем аннотированное поле @TempDir (1’).
- Мы проверяем создание этого временного каталога перед выполнением теста (2’).
- Мы создаем файл в этом каталоге и проверяем его существование (3’).
Преимущество подхода расширения JUnit 5 заключается в том, что нам не нужно создавать папку самостоятельно с помощью конструктора, но папка создается автоматически, как только мы аннотируем поле с помощью @TempDir.
Мы переключаем наше внимание на замену пользовательского правила. Собственные правила особенно полезны, когда некоторые типы тестов требуют одинаковых дополнительных действий до и после их выполнения.
В JUnit 4 нам нужно было, чтобы наши дополнительные действия выполнялись до и после выполнения теста. Следовательно, мы можем создавать собственные классы, реализующие интерфейс TestRule. Для этого необходимо переопределить метод apply(Statement, Description), который возвращает экземпляр Statement. Такой объект представляет тесты в среде выполнения JUnit и Statement#evaluate() их запускает. Объект Описание описывает отдельный тест. Мы можем использовать его для чтения информации о тесте посредством отражения.
Чтобы наглядно показать, как определять наши собственные правила, мы смотрим на листинг 6, где мы делаем следующее:
- Мы объявляем наш класс CustomRule, реализующий интерфейс TestRule (1).
- Мы сохраняем ссылки на поле Statement и поле Description (2) и используем их в методе apply, который возвращает CustomStatement (3).
Заинтересованы в Java? Посетите наши тренинги.
Каталин Тудоуз
Эксперт по Java и веб-технологиям
Первоначально опубликовано на https://www.luxoft-training.com.