Стоит задача написать юнит-тесты для базы на MSSQL Server с количеством хранимых процедур в 1500 штук и количеством таблиц в БД около 600 штук. База писалась и поддерживалась несколькими разработчиками в течение 12 лет примерно, и сейчас также продолжает периодически изменяться.
В качестве инструмента для тестирования я выбрал tSQLt - tsqlt.org/.
1.Какую практическую пользу может принести такое юнит-тестирование.
Что приходит на ум сразу - в ситуации, если охватить каждую ХП хотя бы одним позитивным тестом, то в случае, когда от одной таблицы БД зависят несколько ХП, и разрабочик БД меняет структуру данной таблицы, потом меняет, допустим, код одной из ХП, а про остальные ХП, зависящие от таблицы, забывает, то наши тест-кейсы ожидаемо провалятся на этих ХП, тем самым просигнализировав разрабу, что тут требуется его внимание. Короче говоря, получается регрессионное тестирование.
Может быть ли извлечена из такого юнит-тестирования еще какая-то польза?
2. Распространенная практика в тест-дизайне - искать граничные точки и писать для них тесты. Но представим себе несколько таблиц, которые соединяются джойнами, пусть даже всего 3. Сколько тест-кейсов можно составить, то есть сколько различных вариантов может быть - когда одна таблица пуста, 2 другие содержат записи, или наоборот? Комбинаторика подсказывает нам, что такое число будет вычисляться по формуле факториала. А еще в ХП есть куча разных условий на сравнение с определенным значением, то это число еще возрастает.
Т.е. разумным представляется писать по одному тесту на одну ХП, в котором будет проверяться, что ожидаемый результат теста будет равен возвращенному ХП. Тем более, что повторюсь, мне охватить надо, до 1500 ХП.
Какие в данном случае могут быть best practices? Такой подход имеет право на жизнь?

Дело в том, что тестами необходимо охватить именно legacy-код. С функционалом я знакомлюсь по ходу дела.