Отсюда - Одна из возможных версий переезда с MySQL на PostgreSQL
Итак, наше приложение вполне можно считать классическим: Spring Boot на servlet-стеке, некоторые элементы Spring Cloud (Sleuth, Vault), Spring Data JPA, Liquibase, тонна интеграций с другими системами по REST и SOAP, хранение файлов в S3. Для написания тестов используются JUnit 5, Mockito, Testcontainers, WireMock, AssertJ, Awaitility. Ничего необычного.
Все тесты пишутся в рамках единой концепции:
Подавляющая доля тестов является не unit, а end-to-end тестами, которые проверяют ветви бизнес-процессов от края до края. В тестах при необходимости мы конечно же инжектим DAO / сервисы / контроллеры, но только для того, чтобы выполнить секцию “Дано” и/или дёрнуть ассерты. Само же тестируемое действие заключается чаще всего в честных вызовах нашего API посредством http-клиента.
Контекст Spring у нас жирный и поэтому должен подниматься не более, чем один раз за прогон всех тестов. Попытка поднять его второй раз вызывает падение.
Поднимается контейнер с СУБД, файлы данных располагаются в tmpfs, контекст накатывает туда миграции Liquibase точно так, как это происходит на тестовых стендах и в боевом окружении.
Явно прописан spring-профиль test. Все компоненты, содержащие аннотацию @Scheduled, отключены (через @Profile("!test")). Тесты, в рамках которых нужно проверить логику шедулеров, инжектят сервисы этих шедулеров и дёргают бизнес-логику ручками.
Методы, помеченные @Async, выполняются синхронно, чтобы повысить вероятность не потерять возникающие в коде исключения.
Все внешние REST/SOAP зависимости мокаются через WireMock, а клиенты для S3 и т.п. – через Mockito. После каждого теста все моки сбрасываются.
Все кэши отключены.
И, на мой взгляд, самый интересный пункт:
После каждого теста все таблицы в БД полностью очищаются.
Я видел много боли на других проектах, когда разработчики не удаляют и не вставляют отдельные данные между разными тестами, а пытаются их как-то сепарировать, но затем с эволюцией проекта в серединку дописывается новый тест, который меняет одни данные, сам не падает, но ... привет, удачной отладки. И, когда нам получилось гарантировать чистоту таблиц между тестов на нашем проекте, стало видно, насколько же это удобно.
