Есть следующие мысли касательно сабжа. Просьба указать на недостатки

Постановка задачи:

Есть корпоративная база данных. Предназначена для ввода в нее каких-то данных, их хранении и последующей обработке. Например, расчет зарплаты, учет каких-либо заказов итд.
База данных достаточно сложная (то есть один человек не в состоянии держать в голове все взаимосвязи и помнить, какая процедура откуда вызывается) и постоянно модифицируется. Стоит задача при вносе любых новых изменений не совершать подвигов по отладке внезапно переставших работать процедур, а спокойно их делать, не боясь, что придется из своего кармана компенсировать ошибки в расчете

Путь решения

Мне на данный момент видется только один выход — тестирование работоспособности базы данных.

делать это можно несколькими способами:
1) Можно завести штат тестеров и заставить их выполнять эту работу.
Но: тестеры не помогут с отладкой (если сразу видно, что есть ошибки, но совершенно непонятно, откуда они). Кроме того, если рассматривать БД, которая делается "под себя" отделом АСУ, то тестеров там как правило нет.
2) Использовать функциональное тестирование БД. То есть тестировать крупные функциональные модули. Например, тест процедуры расчета зарплаты сотрудников. Или тест расчет общей наработки в часах по всем машинам в автохозяйстве, итд. Какие проблемы здесь — нужно очень много тестовых данных и тесты сами получаются очень сложными. Этот вопрос уже здесь рассматривался, и похоже, решения не нашел.
3) Использовать модульное( UNIT) тестирование БД. Предлагаю рассмотреть этот вопрос более подробно.

Что такое unit — тестирование?

Unit тестирование (или модульное тестирование) ставит своей целью проверить каждый модуль (unit) программы на работоспособность.

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

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

Приведу пример из своей области, но могу то же самое проделать с другой
(если скажете, что в вашей области это неприменимо)

Есть такси. есть водители, которые получают и выполняют заказы. С каждого заказа водитель должен сдать какую-то сумму денег. Сумма меняется в зависимости от типа заказа, продолжительности, стоимости, доп условий итд. Необходимо вести учет денег, сдаваемых водителями.

Как это может быть реализовано.

Есть таблицы — архив заказов, архив платежей водиетей, сальдовая таблица. Есть встроенная процедура "рассчитать текущий баланс водителя". Что она делает: суммирует суммы сдачи за кажый заказ начиная с даты последнего сальдо (предположим, что сумму сдачи за заказ считает другая процедура в другом месте) и вычитает из полученного сумму всех его платежей тоже начиния с даты сальдо.

Так вот, тестированию такая структура поддается плохо — потому что надо подготовить большое количество данных (забить тестовые заказы и платежи), и написать тест, который учтет все возможные варианты. В более сложных случаях это может быть и практически невозможно.

Но: описанная структура является на самом деле не
модульным тестированием, а фукнциональным, несмотря на то, что тестируется вроде бы отдельный маленький модуль всей БД. Кроме того, написание теста для такой процедуры — это на 80% проверка умения SQL сервера выполнять SQL запросы — выбирать и агрегировать данные, что протестировано до нас и точно работает

Следовательно, нужно разбивать данную процедуру на более мелкие и тестировать уже их (сразу оговорюсь, проблемы с производительностью я не рассматриваю).
Например:
Для каждой операции, влекущей начисление (снятие) денег со счета водителя вводится понятие транзакции. Придется для каждого типа заказа и варианта расчета его стоимости придумать свой тип транзакции, который будет считать стоимость только своего заказа. При попадании в базу нового заказа в таблицу "журнал транзакций" будет делаться запись с типом транзакции, кодом водителя и всеми параметрами, влияющими на сумму сдачи. Аналогично при вносе водителем денег будет создаваться транзакция со свомм типом и параметрами.
Процедура расчета баланса просто сделает селект по всем строкам с датой больше сальдо и просуммирует суммы (извините за тавтологию) транзакций (считать их можно через user functions, параметрами которых будут уже физические величины, а не ссылки на строки)) и сгруппирует их по водителям.
В данной структуре саму процедуру расчета тестировать не надо, так как любые изменения процедуры расчета будут касаться только транзакций, а уверенность в том, что она суммирует правильно обеспечивается SQL сервером Кроме того, такая структура удовлетворяет принципу OCP — закрытость для изменений и открытость для расширений, что хорошо само по себе даже без тестирования
Тестировать надо будет только процедуру (триггер), выбирающий нужный тип транзакции в зависимости от заказа(здесть нужна одна тестовая строка данных) и сами транзакции (здесть только параметры и возвращаемое значение). Все!

Вот в общем вся идея. Если БД не поддается тестированию — значит что-то сделано не так.
Буду признателен за примеры, которые не укладываются в данную схему.