AssertJ
Тема дорожной карты · Java
AssertJ — это гибкая библиотека утверждений для Java, значительно повышающая читаемость и выразительность модульных и интеграционных тестов, написанных с JUnit 5 или TestNG. Вместо статических вызовов assertEquals(expected, actual) из JUnit, AssertJ позволяет создавать цепочки утверждений на естественном языке, например assertThat(result).isNotNull().hasSize(3).contains("Java"), обеспечивая удобное автодополнение в IDE и значительно более описательные сообщения об ошибках. Основной модуль поддерживает утверждения для всех типов JDK, включая String, List, Map, Optional, Path, Stream и LocalDate, тогда как модули расширения assertj-guava и assertj-db нацелены соответственно на структуры Guava Multimap и состояние реляционных баз данных. AssertJ беспрепятственно интегрируется с Mockito для проверки взаимодействий с моками и с Testcontainers для утверждений о состоянии на основе контейнеров в интеграционных тестах, делая его стандартным инструментарием утверждений в современных Java-проектах. Использование assertThatThrownBy(() -> service.call()).isInstanceOf(IllegalArgumentException.class) — лаконичный, идиоматичный для AssertJ способ проверить поведение исключений без загромождения тестов блоками try-catch.
Как это работает
AssertJ использует JUnit 5 как де факто unit-test framework (@Test, @ParameterizedTest, @BeforeEach), AssertJ или Hamcrest для fluent-ассертов, Mockito для моков, Testcontainers для подъёма реальных БД/сервисов в Docker для integration-тестов, REST Assured для HTTP API-тестов. Spring Boot имеет свои test-slice (@WebMvcTest, @DataJpaTest), загружающие минимальный контекст.
Когда применять
JUnit 5 + AssertJ — дефолтный стек. Testcontainers — для любого кода, касающегося реальной БД; мок БД прячет реальные баги (constraint violations, ошибки запроса). Mockito — осторожно; over-mocking тестирует мок, не код. Тесты в CI на каждый PR; валите билды на flake.
Типичные ошибки
Ловушки AssertJ: тесты, делящие state через static-поля; мокинг всего, пока тест — это просто verify(...)-вызовы; медленные Spring Boot integration-тесты, потому что каждый тест поднимает весь контекст (используйте slice-тесты); flaky-тесты оставлены — каждый подрывает доверие.