AssertJ как способ значительно улучшить код ваших тестов

Привет, Хабр!

В 2019-2020 годах на одном из проектов я был идейным вдохновителем перехода на JUnit 5. Для проверок мы использовали стандартные ассерты и Hamcrest. Тогда мне казалось, что этого более чем достаточно. Один из наших lead-инженеров предлагал AssertJ как более «модное и молодёжное» решение, но поддержки эта идея не получила. Я был одним из тех, кто выступал против AssertJ. Каюсь, был грешен :)

За последние пару лет, несмотря на менеджерскую позицию, я написал свыше пятисот тестов, и мой подход к тестированию претерпел значительные изменения. В этой статье я постараюсь объяснить, почему AssertJ — это лучшее решение для проверок в тестах, существующее сегодня (год 2022 от Р.X.). Разумеется, всё ниже сказанное — это моё субъективное мнение.

1. Переходите на JUnit 5, если ещё нет

Да, совет «капитанский», но действительно важный. Старые версии должны кануть в Лету, в том числе и JUnit 4. Во всех проектах, где я участвую, явным образом через checkstyle запрещаю использование классов из JUnit 4 (пример тут).

<module name="IllegalImport">
    <property name="regexp" value="true"/>
    <property name="illegalClasses"
              value="^org\.junit\.Test, ^org\.junit\.jupiter\.api\.Assertions, ^org\.junit\.Test, ^org\.junit\.jupiter\.api\.Assertions\..*"/>
    <property name="illegalPkgs" value="^org\.hamcrest"/>
</module>

Делаю так, потому что полностью убрать JUnit 4 с classpath часто невозможно, например, из-за Testcontainers (см. issue).

2. Структурируйте свои тесты

Я приверженец AAA-подхода: Arrange-Act-Assert. Вы можете также использовать Given-When-Then — принципиально сути это не меняет. Требуйте от разработчиков, чтобы в каждом тесте был ассерт! Для контроля можно (и нужно!) использовать статический анализатор, например, PMD и его JUnitTestsShouldIncludeAssert.

Я не фанат слепого поклонения каким-либо правилам и допускаю в одном тесте несколько действий и несколько проверок. Вместе с тем использование AssertJ сильно облегчает переход к парадигме один тест — один ассерт. Достигается это за счёт fluent API — одной из ключевых особенностей AssertJ.

@Test
void shouldSatisfyContract() {
    assertThat(check)
        .hasType(Index.class)
        .hasDiagnostic(Diagnostic.INVALID_INDEXES)
        .hasHost(PgHostImpl.ofPrimary());
}

Больше примеров тут.

3. Откажитесь от традиционных ассертов

Ассерты в стиле JUnit были очень хороши... лет 20 назад. Сейчас они устарели и представляют собой пример не самого удачного дизайна. Сможете сходу вспомнить порядок следования expected и actual?

final String actual = doSomething();
// Так?
Assertions.assertEquals(actual, "expected");
// Или так?
Assertions.assertEquals("expected", actual);

А сможете научить всех своих инженеров, включая новичков, не путать их местами?

AssertJ by design лишён этой проблемы:

assertThat(actual).isEqualTo("expected");

4. Делайте ваши тесты более читаемыми, используя естественный язык

При использовании традиционных ассертов код ваших тестов выглядит искусственным и с трудом читается вслух. Сравните:

final Account a = makeAccount();
assertEquals("RussianAccount{id=1, currency=BaseCurrency(isoCode=RUB), number=30102810100000000001, active=true, balance=0, holder=Party{Revolut LLC, type=LEGAL_PERSON, tax identification number=7703408188, id=1}, chapter=BALANCE}",
    a.toString());

и

final Account a = makeAccount();
assertThat(a)
    .hasToString("RussianAccount{id=1, currency=BaseCurrency(isoCode=RUB), number=30102810100000000001, active=true, balance=0, holder=Party{Revolut LLC, type=LEGAL_PERSON, tax identification number=7703408188, id=1}, chapter=BALANCE}");

Вот ещё пример:

// JUnit
assertEquals(1, cache.size());

// AssertJ
assertThat(cache)
    .hasSize(1);

AssertJ предоставляет красивые и удобные методы для проверки типовых вещей: эквивалентности, хэш кода, размера коллекции и т.д.

assertThat(second)
    .isNotEqualTo(first)
    .doesNotHaveSameHashCodeAs(first);

assertThat(index.getIndexNames())
    .hasSize(2)
    .containsExactly("index3", "index4")
    .isUnmodifiable();

Если вы работали с BigDecimal в тестах, то, вероятно, сталкивались с проблемой проверки значений из-за разного масштаба: обычно вместо equals приходится применять compareTo. AssertJ частично устраняет эту проблему за счёт метода isEqualByComparingTo:

@Test
void moneyProblem() {
    final BigDecimal one = new BigDecimal("1.000");
  
    // AssertJ
    assertThat(one).isEqualByComparingTo(BigDecimal.ONE); // pass
  
    // JUnit
    Assertions.assertEquals(0, one.compareTo(BigDecimal.ONE)); // pass
    Assertions.assertEquals(BigDecimal.ONE, one); // fail
}

5. Полностью откажитесь от Hamcrest

Любой код живёт, развивается и рано или поздно умирает. Какие-то вещи сначала становятся популярными, а потом выходят из моды. Не цепляйтесь за устаревающие проекты. Hamcrest не радует нас новыми версиями с октября 2019. Просто замените его более современным решением:

// Было - Hamcrest
assertThat(indexes.stream()
    .map(TableNameAware::getTableName)
    .collect(Collectors.toSet()), containsInAnyOrder("t", "demo.t", "test.t"));

// Стало - AssertJ
assertThat(indexes.stream()
    .map(TableNameAware::getTableName)
    .collect(Collectors.toSet())).containsExactlyInAnyOrder("t", "demo.t", "test.t");

6. Используйте возможности функционального подхода

AssertJ поддерживает функциональный подход и позволяет вам преобразовывать исходные данные. Предыдущий пример можно значительно улучшить, сократив количество кода и увеличив его читаемость:

assertThat(indexes)
    .flatExtracting(TableNameAware::getTableName)
    .containsExactlyInAnyOrder("t", "demo.t", "test.t");

 А вот как можно работать с Optional<>:

assertThat(statisticsMaintenance.getLastStatsResetTimestamp())
    .isPresent()
    .get()
    .satisfies(t -> assertThat(t).isAfter(testStartTime));

7. Расширяйте AssertJ для использования с вашими собственными типами

AssertJ предоставляет абстрактный базовый класс AbstractAssert<>, расширяя который, вы можете добавить поддержку своих собственных типов и методов для проверки. В некоторых случаях это позволяет заметно сократить количество тестового кода и повысить его выразительность. Пример:

assertThat(check)
    .hasType(Column.class)
    .hasDiagnostic(Diagnostic.COLUMNS_WITHOUT_DESCRIPTION)
    .hasHost(PgHostImpl.ofPrimary())
    .executing()
    .isEmpty();

8. Получайте понятные логи, если тест упал

Выше я совсем не упомянул про поддержку в IntelliJ IDEA (code completion) и про то, что AssertJ даёт весьма подробные и читаемые логи, если тест падает:

[All diagnostics must be logged] 
Actual and expected should have same size but actual size is:
  10
while expected size is:
  12
Actual was:
  ["1999-12-31T23:59:59Z	db_indexes_health	invalid_indexes	0",
...

Можно добавить описание к последующему шагу теста:

@Test
void completenessTest() {
    assertThat(logger.logAll(Exclusions.empty()))
        .as("All diagnostics must be logged")
        .hasSameSizeAs(Diagnostic.values());
}

 А ещё можно переопределить сообщение об ошибке через overridingErrorMessage(), но в большинстве случаев это не требуется.

9. Защищайте себя от неправильного использования AssertJ

Если вы ещё не поняли, то я обожаю статический анализ кода. Эта волшебная штука, если её правильно приготовить, может делать за вас огромное количество работы!

Код AssertJ активно использует аннотацию @CheckReturnValue: методы assertThat(), as(), overridingErrorMessage() и некоторые другие размечены ею.

Если вы забудете после assertThat() вызвать какой-нибудь метод проверки, то SpotBugs упадёт с ошибкой RV_RETURN_VALUE_IGNORED.

Основная хитрость здесь в том, что нужно для SpotBugs явно выставить порог предупреждений в Low.

Для Maven-плагина:

<configuration>
    <includeTests>true</includeTests>
    <effort>Max</effort>
    <threshold>Low</threshold>
</configuration>

Для Gradle-плагина:

spotbugs {
    effort = 'max'
    reportLevel = 'low'
}

* * *

На этом всё. Больше примеров использования AssertJ вы сможете найти в моих проектах на GitHub.

Надеюсь, эта статья поможет сделать код ваших тестов чуточку лучше.