Модульное тестирование TSQL

Question

Есть ли кто-нибудь, кто пишет модульные тесты для своих хранимых процедур, триггеров, функций TSQL и т. Д.

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

Я собирался просто свернуть свои собственные, используя MsBuild Extensions, чтобы вызвать тесты. Однако я знаю о http://www.tsqltest.org/ и http://tsqlunit.sourceforge.net/.. Я также знаю, что в TFS есть sql-тестирование.

Я просто хотел посмотреть, что люди в реальном мире делают и есть ли у них какие-либо предложения.

Спасибо

Answer 1

Критические части:

• Сделать автоматизированным и интегрированным с вашей сборкой / тестом (так что у вас есть зеленый или красный из вашей сборки)
• Упростите добавление нового теста
• Поддерживайте ваши тесты в актуальном состоянии

Дополнительно:

• тестовые условия неудачи в вашем коде
• убедитесь, что ваши тесты очищаются после сами (пример TSqlTest скрипты используют @beforeCount и переменные @afterCount для проверки очистка)

Answer 2

Хранимые процедуры. Я обычно включаю тестовые запросы в комментарии в заголовке SP и записываю правильные результаты и время запросов. Однако это все равно остается ручным упражнением.)

Функции. Опять же, поместите операторы SQL в заголовок с той же информацией.

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

Однако это все еще ручной процесс. Но так как я думаю, что нужно намеренно проектировать артефакты SQL, чтобы они были полностью разобщены (например, нет SP, вызывающих SP, то же самое с функциями, и еще один удар по триггерам IMHO), это относительно менее сложно.

Answer 3

Вы пытались использовать API red-gate.com?

У них есть набор продуктов для сравнения в SQL Server, а API-интерфейс предоставляет практически те же функции программно.

http://help.red -gate.com / помощь / SQLDataCompareAPIv5 / 4 / ен / GettingStartedAPI.html

Answer 4

Я сделал это в Java, используя dbunit.

По сути, все, что вы делаете в базе данных: возвращает набор результатов или изменяет состояние базы данных.

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

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

Учитывая, что ваша база данных находится на базовом уровне, любой результирующий набор является детерминированным (если ваш sp детерминирован, тем более, если он делает "select random ();").

Получите базовый набор результатов всех ваших SP, сохраните их как снимки с помощью dbunit или любого другого инструмента, который вы используете.

Чтобы проверить операции, которые не меняют состояние, просто проверьте, что набор результатов, который вы получаете, является тем, который вы изначально получили. Чтобы проверить операции, которые изменяют базу данных, протестируйте эту базовую линию + операция = ожидаемое изменение. После каждого теста, который потенциально изменяет базу данных, восстанавливайте его до базового уровня.

По сути, возможность восстановления до базовой линии делает возможным тестирование.

Answer 5

Я использовал тестирование базы данных, встроенное в Visual Studio 2008 Database Edition, в проекте здесь. Это работает хорошо, но больше похоже на стороннюю поддержку Visual Studio, чем на собственный компонент. Некоторые из болей, которые я чувствовал с этим:

• Поскольку код SQL находится в файлах res и один файл кода может включать в себя несколько тестов, поиск тестов по именам таблиц / столбцов не так прост.
• Поскольку несколько тестов находятся в одних и тех же кодовых файлах, у вас возникают раздражающие коллизии имен переменных (например, если у вас есть два теста в одном кодовом файле, все утверждения для этих тестов должны иметь уникальные имена; это означает, что ваши имена утверждений, вероятно, будут выглядеть как «testname_assertionname», что на самом деле не должно быть обязательным).
• Рефакторинг ваших тестов не прост - например, если вы хотите переместить тест из одного файла кода в другой, самый простой способ - создать тест с нуля в новом файле, потому что в нем есть кусочки теста разбросаны о файле res и файле кода.

Все это говорит, как я начал - это работает хорошо. К сожалению, мы еще не добавили эти тесты на наш сервер непрерывной интеграции, поэтому я не могу комментировать, насколько легко автоматизировать выполнение этих тестов. Мы используем TFS для CI, и я предполагаю, что автоматизация тестов будет работать очень похоже на автоматизацию стандартных модульных тестов; Другими словами, похоже, что должна быть командная строка MSTest для запуска тестов.

Конечно, это вариант, только если у вас есть лицензия на запуск Visual Studio 2008 DB Edition (что, как я понимаю, теперь включено в лицензию VS 2008 Pro).