В продолжение предыдущей заметки.

Написала юнит тесты к очередной задаче. Тестируемый метод A был приватным, поэтому в тестах пришлось вызывать публичный метод B, вызывающий А. Метод А делает выполняет некую логику и сохраняет результат в БД. Вроде бы все просто, надо дернуть В, и проверить что в БД оказались нужные данные. Но на деле оказалось, что метод B вызывает также методы C, D, E... которые требуют еще данные для собственных расчетов. Когда я замокала все побочные вызовы, код выглядел мягко говоря, не очень понятно.

Решила применить тот же подход, что в предыдущей заметке - сделать интеграционные тесты с testcontainers.
Настроила liquibase, добавила тестовые данные, замокала пару вызовов... Тесты прошли успешно и стали выглядеть гораздо чище. Но в консоли обнаружилось несколько ошибок.
Оказалось, что приложение использует несколько схем в БД, и одна регулярная таска, которая запускается при старте приложения, пытается получить данные таблиц из разных схем и падает. И хоть на работу теста это не влияет, но некрасиво оставлять такие грязные логи. К тому же, если в будущем тесты упадут, это может запутать разработчика, который будет фиксить багу.

Liquibase для работы с кастомными схемами уже был настроен. Дальше разобралась, как настроить несколько датасорсов для работы с разными схемами. Теперь тесты стали полностью эмулировать работу приложения в слое обращения к БД. И можно легко создавать более сложные интеграционные тестовые сценарии.