А зачем вообще БД в модульном тесте, что он тестирует?

все же, есть подозрение, что мокать не нужно. а нужно подключаться к чему-то более-менее реальному. либо embedded либо как выше писали testcontainers

методы обращения к БД

мокать нужно свои интерфейсы

тест тестирует либу

не Ваш код

И как тут поможет мок? Вы будете тестить, как ваш код работает с моком, который ведёт себя именно так, как вы сами напишете, а не как ведёт себя реальная БД.

нужно проверить, что внутри функции вызываются методы работы с БД в нужной последовательности

А откуда уверенность, что эта последовательность вызовов сделает именно то, что нужно?
По мне так такие тесты слегка бесполезны и неподдерживаемые.

закрепляет изменения. если что-то в коде поменяется и повалятся модульные тесты, станет понятно, где нужно поправить

вы уверены? есть подозрение что повалится только тот единственный тест, который будет по-факту копией оригинального метода.

либо мы чего-то не понимаем в вашем случае, либо вы действительно зашли слишком далеко.

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

Обычно есть некоторый интерфейс с контрактом.

И есть некоторый код, который реализует этот интерфейс, например с использованием ReactivePg.

И тестировать нужно именно контракт этого интерфейса. Скажем store(something); take(something) должны правильно работать.

И для этого базу мокать нельзя. а нужно подключаться к реальной БД (например embedded, in memory) которая сможет исполнить SQL.  

таким образом реализацию можно протестировать на предмет соответсвия контракту.

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

В крайнем случае можно замокать Row объект, чтобы протестировать свой маппер.

ого

не думал что он на котлине написан)

А есть ссылка на статью?