Мы изучаем использование tSQLt для тестирования модулей SQL Server, но до этого нам нужно понять, будем ли мы тратить время на то, чтобы работать с нашей настройкой. Причина, по которой я прошу об этом, состоит в том, что у нас есть две базы данных, одна из которых довольно «нормальная» (наша производственная база данных), а другая - база данных «API», которая обеспечивает ограниченный доступ к этой базе данных посредством хранимых процедур, которые «переворачивают» «между учетной записью пользователя, к которой вы обращаетесь к базе данных API, и олицетворенной учетной записью для производственной базы данных. Таблицы в производственной базе данных не доступны напрямую, а через синонимы. Транзакционное предоставление осуществляется из хранимой процедуры «точка входа» в базе данных API.SQL-функции, которые могут вызвать проблемы для tSQLt
Есть две основные вещи, которые мы хотим проверить;
(1) Разрешения безопасности объектов, поскольку мы можем столкнуться с проблемами при работе с общими объектами, когда мы «забудем» правильно установить безопасный доступ между сборками.
(2) Хранимые процедуры/функции API. Я думаю, что мы можем тестировать некоторые из функций относительно независимо, но я не могу понять, как легко сохранить хранимые процедуры.
- Поддерживает ли tSQLt тестирование разрешений безопасности?
- Я вижу, что есть проблемы с перекрестным тестированием базы данных и синонимами, но информация довольно историческая. Они были решены сейчас?
- Почему tSQLt требует разрешения CLR?
- Должен ли быть установлен код tSQLt в базе данных, с которой он собирается протестировать, или мы можем запустить его для базы данных в том же экземпляре?
- пункт Список
Если вы собираетесь запускать 'test' в своей производственной базе данных, я думаю, вам не нужно использовать' tSQLt'. Вы можете просто создать инструкцию T-SQL, которая обнаруживает ошибки и запускает ее с заданием или вручную. Структура 'tSQLt' - это просто оболочка (пакет с процедурами/функциями T-SQL и несколько CLR), которые вы можете использовать для тестирования. Чтобы использовать его, вы должны включить CLR, и вы должны «развернуть/создать» эти объекты в своей базе данных. Я полагаю, для вашего случая вам будет лучше разработать процедуру тестирования. – gotqn
Я должен уточнить, что «производственная» база данных - это копия производственной базы данных на нашем тестовом сервере dev, а не фактическая база данных! У нас есть веб-сервис, который ведет переговоры с базой данных API, которая рассказывает о «производственной» базе данных. Эта «производственная» база данных обычно используется приложением, развернутым над citrix. –
В принципе, 'tSQLt' даст возможность сравнить результат выполнения с предопределенным результатом. Например, вам нужно написать код, который 'проверяет, имеет ли пользователь A права на объект B', а затем с помощью' tSQLt' он будет поднимать или не поднимать ошибку (в зависимости от вашего случая). Таким образом, вам нужно выполнить «трудную» работу, и если вы напишете инструкцию T-SQL, которая является «поиском проблем», вы можете просто выполнить ее. Кроме того, модульное тестирование предназначено для тестирования результатов для отдельных объектов, и в вашем случае я думаю, что вы собираетесь работать с более сложной бизнес-логикой. – gotqn