Модульное тестирование VS для процедур базы данных inMemory, которые могут быть интегрированы с конвейером непрерывной доставки

Question

Итак, я пытаюсь найти способ надлежащего модульного тестирования процедур базы данных в Visual Studio, чтобы я мог интегрировать его в наш конвейер развертывания.

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

Я могу либо:

1. делать откат после каждого юнит-теста (но есть некоторые процедуры, которые содержат commit, поэтому даже если I rollback в c#, некоторая часть все равно будет зафиксирована)

2. создать тестовую базу данных (в моем случае это не вариант)

3. создать базу данных в памяти (я предпочитаю эту опцию. Я проверил SQLite. Однако, похоже, она не поддерживает процедуры)

Любые советы или предложения приветствуются

Answer 1

3. создать базу данных в памяти (я предпочитаю эту опцию. Я проверил SQLite. Однако, похоже, он не поддерживает процедуры)

SQL Server не поддерживает параметр в памяти

2. создать тестовую базу данных (не вариант в моей ситуации)

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

1. делать откат после каждого юнит-теста (но есть некоторые процедуры, содержащие коммит, поэтому даже если я откатюсь в c #, некоторая часть все равно будет быть преданным)

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