Использование TSQLUNIT для модульного тестирования SQL: вам не нужно дублировать код SQL?

Question

Я рассматриваю возможность написания некоторых модульных тестов для моих хранимых процедур Tsql, у меня есть две проблемы:

1. Мне придется написать много SQL для создания тестовых фикстур (тестовые данные, подготовленные в процедурах _setup)

2. Мне придется «переписать» мой запрос в процедуре тестирования, чтобы получить результаты для сравнения с результатами хранимой процедуры, которую я тестирую.

Учитывая, что в моей БД есть сотни таблиц и действительно сложные хранимые процедуры ... Я не понимаю, как это сэкономит мне время ?? Какие-нибудь мысли? я что-то пропустил? Есть ли другой путь?

Answer 1

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

Относительно ваших проблем:

1. Если вы поместите какие-либо данные, необходимые для модульного тестирования вашей хранимой процедуры (процедур), в файлы XML, которые могут быть прочитаны до выполнения модульного теста (тестов), вы можете прочитать данные, используя стандартные процедуры API для чтения. XML-данные и, возможно, повторно использовать данные для нескольких тестов. Запускайте каждый тест в контексте транзакции, откат которой выполняется в конце теста, чтобы можно было настроить общую среду один раз в начале выполнения теста, а не выполнять много шагов для каждого отдельного теста. Модульные тесты могут быть объединены с автоматическими ночными процессами сборки для дополнительной защиты вашего кода.

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

2. Вам не нужно переписывать запрос для сравнения результатов. Стандартный сценарий может выглядеть примерно так:

   1. загрузить данные испытаний и подготовить среду
   2. начать транзакцию
   3. запустить хранимую процедуру с использованием тестовых данных
   4. сравнить фактический результат с ожидаемым, используя операторы Assert
   5. если фактический и ожидаемый выходные данные не совпадают, тест не пройден
   6. , если фактический и ожидаемый выходной сигнал совпадают, тест проходит успешно
   7. транзакция отката
      /...
      Повторите шаги с 2 по 7 для любых дополнительных тестов
      ... /
      
   8. Очистка тестовой среды

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

Надеюсь, это поможет,

Bill

Answer 2

Что меня интересует, так это то, почему вы планируете писать модульные тесты? У вас есть проблемы с базой данных? Сложно ли вносить изменения? Зависит ли руководство от повышения в зависимости от юнит-тестов?

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

Есть также серьезные риски с юнит-тестами:

1. Люди начинают рассматривать модульные тесты как «гарантию качества». Просто продолжайте взламывать, пока юнит-тесты не дадут зеленый свет, и тогда он будет достаточно для производства.
2. Небольшие изменения, которые раньше были «быстрым исправлением», будут увеличиваться, потому что они требуют (изменений) модульных тестов. Таким образом, модульные тесты делают вас менее гибкими.
3. Юнит-тесты часто проверяют многие вещи, которые не имеют значения для тех, кто использует производственную систему. Таким образом, юнит-тесты заставляют вас тратить ресурсы на вещи, о которых заботятся только юнит-тесты.

Извините за напыщенную речь (у меня был плохой опыт с юнит-тестами.)

Answer 3

Теоретически, модульное тестирование (в общем) означает больше времени на предварительное написание тестов, но в дальнейшем должно облегчить вам задачу. Например, вложенное время приносит дивиденды позже, когда у вас есть возможность очень легко обнаружить ошибки регрессии. Запись в Википедии о модульном тестировании имеет хороший обзор общих преимуществ.

Будет ли это полезно для вас на практике - сложно ответить на вопрос - зависит от проекта.

Что касается «необходимости переписывать запрос для проверки результатов запроса», очевидно, это ничего не докажет. Я предполагаю, что вам нужно настроить тестовые данные, которые будут возвращать предсказуемый результат при выполнении запроса (или чего-либо еще), а затем проверять этот конкретный результат. Таким образом, вы проверяете запрос на соответствие своей ментальной модели, а не проверяете запрос на его копию.

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