Учитывая, что команда унаследовала устаревший проект, в котором не контролируется схема БД. Это означает, что любой в нашей организации может вносить изменения в большую корпоративную БД, доступную для всех других команд. Конечно, изменения сведены к минимуму для обеспечения обратной совместимости. Однако я не вижу смысла использовать частичные (несколько таблиц) встроенные или находящиеся в памяти базы данных для тестирования персистентного уровня (DAO).
Какой риск действительно может быть покрыт, когда наши SQL-скрипты не синхронизированы с базами данных PROD или SIT? По крайней мере, до тех пор, пока что-то не сломается, и мы не поймем, что наши SQL-скрипты не обновлены.
Мне нужна другая пара глаз (+ мозг), чтобы понять такую стратегию тестирования.
Какой тип тестирования вы бы применили к слою персистентности в этой сложной ситуации?
Заранее большое спасибо,