Архитектура JUnit 5. Часть 4

01.09.2020 101
Предыдущая часть

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

Listing 3. The JUnit5ExceptionTester class

В примере с 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 — 20 строк. И нет необходимости инициализировать и использовать дополнительные правила. Каждый метод тестирования в JUnit 5 содержит одну строку.

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

Listing 4. The JUnit4RuleTester class
В этом примере мы делаем следующее:
  1. Декларируем поле TemporaryFolder с аннотацией @Rule и инициализируем его. Аннотацию @Rule необходимо применить либо к общедоступному полю, либо к общедоступному методу (1).
  2. Используем поле TemporaryFolder для создания папки и файла (2). Они находятся в папке Temp профиля пользователя в операционной системе.

  3. Проверяем наличие временной папки и временного файла (3).

Теперь рассмотрим новый подход в JUnit 5 (Пример 5).

Listing 5. The JUnit5TempDirTester class
В примере с JUnit 5 выше мы делаем следующее:

  1. Декларируем поле с аннотацией @TempDir (1’).

  2. Перед выполнением теста проверяем создание временной директории (2’).

  3. Создаем файл в этой директории и проверяем его наличие (3’).

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

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

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

Listing 6. The CustomRule class

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

  1. Декларируем класс CustomRule, который реализует интерфейс TestRule (1).

  2. Сохраняем ссылки на поле Statement и поле Description (2) и используем их в методе apply, который возвращает CustomStatement (3).


Автор Catalin Tudose, Java and Web Technologies Expert

Продолжение

Расскажи друзьям:

 
Оценка и обучение ИТ-специалистов по ключевым направлениям разработки программного обеспечения. Курсы от экспертов-практиков по языкам программирования, системному и бизнес-анализу, управлению проектами, тестированию ПО, архитектуре ПО. Luxoft Training – единственный учебный центр в России, авторизованный IIBA. Действует скидка 10% на обучение физических лиц.
   Подпишись на ежемесячный DigestLT
Успешная форма подписки.
Пользователь только что записался на курс ""
Спасибо!
Форма отправлена успешно.