Это перекрестная публикация статьи, опубликованной в моем блоге, которую вы можете найти здесь .
Что такое JUnit 5?
Согласно его веб-сайту ,
JUnit 5 – это следующее поколение JUnit. Цель состоит в том, чтобы создать современную основу для тестирования на стороне разработчика в JVM. Это включает в себя сосредоточение внимания на Java 8 и выше, а также включение множества различных стилей тестирования.
Эта статья предназначена для всех, кто слышал или не слышал о JUnit 5 и задается вопросом, почему они хотели бы его использовать.
Я не хочу вдаваться в подробности обо всех функциях или о том, как это работает внутри, я просто хочу показать некоторые из новых функций, которые пока наиболее ценны для меня.
Так что давайте сразу перейдем к делу…
Ранее в JUnit тесты получали свои названия по их методам тестирования.
Напр.:
public class AccountTest {
@Test
public void testMethod() {
// do some tests here
}
}
Когда вы запустите его, он выведет test Method в качестве имени теста, которое, вероятно, не очень полезно и, самое главное, не читается. Тест должен быть удобочитаемым для человека, потому что тесты – это единственная настоящая документация по коду, которая не устарела. Поэтому люди начали пытаться придумать несколько более описательных названий тестов.
public class AccountTest {
@Test
public void withdrawSomeAmountGreaterThanCurrentBalanceFailsWithException() {
// do some tests here
}
}
Лучше? Не так уж и много. По крайней мере, это дает вам некоторое представление о том, что здесь произойдет. Что-то о снятии некоторой суммы со счета, которая превышает текущий баланс. Это должно потерпеть неудачу. Но как сделать его более читабельным? Некоторые разработчики (включая меня) начали нарушать строгое соглашение Java camelCase и начали использовать подчеркивания для разделения аспектов теста, например method__scenario__expectedResult .
public class AccountTest {
@Test
public void withdraw__amountGreaterThanCurrentBalance__failsWithException() {
// do some tests here
}
}
Это немного более читабельно, хотя и режет глаза каждому разработчику Java, который привык к camelCase. Что вы на самом деле хотите, так это использовать любую произвольную строку в качестве имени теста.
Kotlin позволяет вам использовать строковые литералы, такие как напр.
internal class AccountTest {
@Test
fun `should thrown an exception when an amount is withdrawn greater that the current balance`() {
// do some tests here
}
Юнит 5 спешит на помощь. Хотя и не так просто, как в Kotlin, модуль 5 поставляется с аннотацией @DisplayName , которую можно использовать как для тестовых классов, так и для методов. Недостатком является то, что вам все равно нужно создать имя метода:
@DisplayName("An account")
class AccountTest {
@Test
@DisplayName("should throw an exception when an amount is withdrawn greater that the current balance")
void withdrawBalanceExceeded() {
// do some tests here
}
}
Так несмотря на то, что происходит типичное загромождение аннотаций Java, результат (как и в том, что показывает IDE) гораздо более удобочитаем.
Обратите внимание, что вам не нужно использовать общественный больше с методами и классами.
Во время парного программирования с коллегой я копировал и вставлял тесты и описания и просто менял их части для тестирования разных крайних случаев. Она сказала мне, что я должен использовать вложенные тесты. Мы попробовали это, и я сразу же влюбился в эту идею. Вместо того, чтобы проводить такой тест, как этот:
- Счет
- должно выдавать исключение, когда выводится сумма, превышающая текущий баланс
- следует уменьшить баланс на сумму, которая выводится
Вы могли бы сделать что-то подобное
- Счет
- вывод
- должно выдавать исключение, когда сумма превышает текущий баланс
- следует уменьшить остаток на сумму
- вывод
С JUnit 5 это выглядит так:
@DisplayName("An account")
public class AccountTest {
@Nested
@DisplayName("withdrawal")
class Withdrawal {
@Test
@DisplayName("should throw an exception when the amount greater that the current balance")
public void failureBalanceExceeded() {
// do some tests here
}
@Test
@DisplayName("should reduce the balance by the amount")
public void success() {
// do some tests here
}
}
}
Опять же, общее количество строк увеличивается за счет использования @Вложенный как необходимо обернуть тесты внутри вложенного класса но это делает тесты более чистыми.
JUnit 5 построен так, чтобы быть очень расширяемым. Пользовательские или сторонние расширения могут быть добавлены с помощью аннотации @ExtendWith на уровне класса.
Пружинный ботинок
Интеграционные тесты Spring boot, например, теперь выполняются с помощью @Расширить с помощью(SpringExtension.class ) . Обратите внимание, что это работает только с spring-boot 2.x и выше.
Расширение Mockito
Там будет обновлено Расширение Mockito/| которое могло бы сделать что-то подобное:
@ExtendWith(MockitoExtension.class)
class MyMockitoTest {
@BeforeEach
void init(@Mock Person person) {
when(person.getName()).thenReturn("Dilbert");
}
@Test
void simpleTestWithInjectedMock(@Mock Person person) {
assertEquals("Dilbert", person.getName());
}
}
Таким образом, вам не нужно писать Person(Person.class ) или используйте @Mock частное лицо person/| .
Эти новые функции в JUnit 5 имеют свою цену: они несовместимы с тестами JUnit 4. Это называется JUnit Jupiter.
“Но подождите, а как насчет моего существующего набора из 500 тестовых примеров?” вы могли бы спросить. Это не так плохо, как вы могли бы подумать. Команда JUnit поступила разумно, они перенесли весь код JUnit Jupiter и аннотации в отдельный пакет, чтобы иметь как JUnit 4, так и 5 в одной и той же кодовой базе. Вам все равно нужно будет добавить новую платформу JUnit, тесты JUnit 4 называются JUnit Vintage. Есть хорошая статья о миграции, которую вы можете найти здесь .
На самом деле у нас есть проект с сотнями тестов, и мы шаг за шагом переносим их. Все новые тесты пишутся с помощью JUnit 5, и как только нам нужно коснуться существующих тестов, мы переносим их. Это в основном удаляет все JUnit import s и заменяет @До по @beforeEach а также @BeforeClass с помощью @beforeAll .
Хотя саму Java можно было бы значительно улучшить, например, введя метапрограммирование (у которого тоже есть свои недостатки) или, по крайней мере, разрешив использовать строковые литералы в качестве имен методов, чтобы сделать тесты еще более удобочитаемыми, но JUnit 5 намного лучше, чем JUnit 4, и я бы предположил, что в будущем будет много расширений.
Более того, в библиотеке утверждений Junit есть много улучшений, но поскольку я использую AssertJ , я не освещал эту часть. Смотрите документацию JUnit 5 для справки.
Оригинал: “https://dev.to/stealthmusic/why-you-should-start-using-junit-5-5gk2”