Организация объектов tSQLt

Мы используем RedGate в сочетании с SQL Test (tSQLt). Для модульного тестирования мы устанавливаем фреймворк на каждую базу данных.

Есть ли способ использовать инфраструктуру tSQLt таким образом, чтобы ваши модульные тесты и объекты инфраструктуры могли находиться в одном центральном месте, которое затем можно было бы использовать в нескольких базах данных?

Мы также используем SQL Source Control RedGate с TFS в качестве нашего репозитория для отслеживания изменений схемы. Эти изменения продвигаются в следующем порядке среды: Разработка --> Тестирование --> Производство.

Излишне говорить, что добавление фреймворка в сочетании с самими тестами представляет собой большое количество новых объектов SQL (таблиц, хранимых процедур и т. д.) в наших базах данных. В идеале мы хотели бы, чтобы эти объекты находились только в разработке и тестировании и не загромождали нашу производственную базу данных. Мы могли бы пропустить слияние изменений tSQLt в Production, но тогда у нас остались бы неслитые изменения в системе управления версиями тестовой среды до скончания века.

Есть мысли как обойти эту проблему?


person K. Akins    schedule 26.04.2016    source источник
comment
Было бы полезно узнать, как вы в настоящее время продвигаете свои изменения с Dev на Test и на Production. Вы используете инструмент или автоматизированный процесс?   -  person David Atkinson    schedule 28.04.2016
comment
Привет Дэвид, спасибо за ваш ответ. В настоящее время мы используем TFS для ручного переноса изменений с Dev на Test. Это делается через Visual Studio в Source Control Explorer.   -  person K. Akins    schedule 03.05.2016
comment
Под TFS вы подразумеваете средство сравнения схем в Visual Studio?   -  person David Atkinson    schedule 03.05.2016
comment
Извините за задержку с ответом. Мы будем использовать систему контроля версий SQL RedGate для проверки наших изменений в TFS. Затем, по мере продвижения в другие ветки, мы найдем наборы изменений, которые были зарегистрированы с помощью RedGate, и объединим их.   -  person K. Akins    schedule 29.05.2016
comment
Я разместил ответ ниже. Было бы полезно, если бы вы объяснили, как вы применяете свои изменения к своим средам из системы контроля версий.   -  person David Atkinson    schedule 30.05.2016


Ответы (3)


Поскольку вы используете систему управления версиями SQL для управления изменениями в базе данных, правильным решением будет проверка тестов tSQLt. Если вы хотите убедиться, что они не будут переданы в промежуточную или производственную среду, вам необходимо убедиться, что инструменты, которые вы используете для отправки изменений, исключают тесты tSQLt. Если вы используете для этого Redgate SQL Compare, используйте параметр «Игнорировать инфраструктуру и тесты tSQLt». Подробные пояснения см. в документации по продукту. Если вы используете другой инструмент или процесс, оставьте комментарий, и я исправлю этот ответ.

person David Atkinson    schedule 30.05.2016

В настоящее время нет возможности установить tSQLt в отдельную базу данных. Я начал процесс создания независимой базы данных tSQLt, но это, по сути, полная переработка, так что это займет некоторое время.

Тем временем вы можете исключить tSQLt из системы управления версиями SQL: all-tsqlt-content" rel="nofollow">https://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/4901910-faster-way-to-exclude-all-tsqlt-content< /а>

person Sebastian Meine    schedule 26.04.2016
comment
Обратите внимание, что инструкции по этой ссылке устарели. В последних версиях системы управления версиями SQL этот параметр можно изменить на вкладке «Настройка» для базы данных. См. здесь: documentation.red-gate.com/display/SOC4/Comparison+options - person James; 27.04.2016
comment
Спасибо за ваш ответ, Себастьян и Джеймс. Думаю, я рассмотрю этот вариант в крайнем случае, потому что мы беспокоимся о сохранении истории изменений для модифицированных модульных тестов. Таким образом, удаление ссылок из системы управления версиями может быть тем, что нам нужно сделать сейчас, даже если это не идеально. - person K. Akins; 03.05.2016

Если вы по-прежнему хотите, чтобы ваши тесты находились в системе управления версиями, но не хотите продвигать их в среду более высокого уровня, это поведение по умолчанию в Redgate DLM Automation Suite. Вы можете использовать один из подключаемых модулей сервера сборки (например, TeamCity или TFS для сборки/тестирования, а затем Octopus Deploy для выпуска) или сделать все это в PowerShell с помощью SQL Release. https://documentation.red-gate.com/display/SR1/SQL+Release+documentation

Если у вас есть лицензия на Redgate's SQL Toolbelt, возможно, у вас уже есть лицензия на инструменты автоматизации (это изменение предыдущей лицензии); http://www.red-gate.com/products/sql-development/sql-toolbelt/#automation

person Cas    schedule 27.04.2016
comment
Кас, спасибо за ответ, я посмотрю на это. Я считаю, что в настоящее время у нас есть лицензия на SQL Developer Suite. Просто взглянув на страницу RedGate, посвященную этому продукту, неясно, включена ли автоматизация DLM в наш пакет. - person K. Akins; 03.05.2016
comment
Я только что подтвердил, что автоматизация DLM не включена в Developer Suite, и это довольно высокая цена для нас, чтобы заплатить только за использование этой функции, однако я уточню у нашей группы администраторов баз данных, обновлена ​​ли их лицензия. Если нет, я предполагаю, что DLM Automation - единственный способ? - person K. Akins; 03.05.2016