Можно ли повторно использовать условия теста или шаги теста в модульном тесте базы данных SSDT?

Question

Я недавно начал использовать модульные тесты базы данных SSDT. Я обнаружил, что у меня много условий тестирования, которые идентичны, но я не могу найти способ их повторного использования. Сколько раз мне нужно сказать "и может быть возвращена только одна строка"?

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

Я что-то упускаю? Или есть способ повторно использовать эти компоненты, или есть какая-то причина, почему мне не нужно их повторно использовать?

Answer 1

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

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

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

Так что это один из способов решения проблемы "обмена тестовыми данными". Я не знаю другого способа поделиться условиями тестирования, кроме как взломать и взломать базовый код на C#, но я бы не рекомендовал его рекомендовать.

Answer 2

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

В этом разделе есть "Инициализация теста" и "Очистка теста", где вы можете добавить код, который выполняется до и после каждого теста в этом классе.

Ваша общая структура теста будет выглядеть так;

1. "Общие сценарии> Инициализация теста": настройка общих данных (и проверка любых условий инициализации теста).
2. "Мой тест> Предварительное тестирование": выполните любые корректировки данных теста (и проверьте все условия предварительного тестирования).
3. "Мой тест> Тест": выполнить тестируемый код и проверить все условия теста.
4. "Мой тест> Пост-тест": очистить все данные теста (и проверить все условия после теста).
5. "Обычные сценарии> Тестовая очистка": очистка любых общих данных (а также проверка и условия очистки).

Это полдела. К сожалению, похоже, что нет способа запустить одни и те же условия тестирования для ряда тестов.

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

Это может немного ввести в заблуждение, что основной раздел найден в разделе "Очистка теста", так что это немного обойдется.

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

В примере аудита шаг 5. может подтвердить, что [dbo].[Audit] имеет одну запись, а шаг 1. удалит из [dbo].[Audit], вернув счетчик строк в 0.

Answer 3

Аналогичная проблема - дублирование кода настройки / разрыва. Мне нравится иметь тестовый класс для хранимой процедуры. В тестовом классе у меня часто есть много тестов, которые смотрят на побочные эффекты и изменения данных, вызванные выполнением связанной хранимой процедуры.

Мне не нравится, что в каждом классе>80% одинакового кода установки и разборки. Это означает, что у меня есть десятки классов, которые можно изменить, если меняются мои настройки или демонтаж.

С другой стороны, этот пост предполагает, что так и должно быть: что означает "DAMP not DRY", говоря о модульных тестах?