У кого-нибудь был успех в модульном тестировании хранимых процедур SQL?

Question

Мы обнаружили, что модульные тесты, которые мы написали для нашего кода C # / C ++, действительно окупились. Но у нас все еще есть тысячи строк бизнес-логики в хранимых процедурах, которые действительно проверяются в гневе, когда наш продукт внедряется для большого числа пользователей.

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

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

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

Вторая часть моих вопросов заключается в том, будет ли модульное тестирование легче / проще с linq?

Я думал, что вместо того, чтобы настраивать таблицы тестовых данных, вы могли бы просто создать коллекцию тестовых объектов и протестировать свой код linq в ситуации «linq to objects»? (Я совершенно новичок в linq, поэтому не знаю, сработает ли это вообще)

Answer 1

Мы используем DataFresh для отката изменений между каждым тестом, тогда тестирование sprocs относительно просто.

Все еще не хватает инструментов покрытия кода.

Answer 2

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

Некоторые другие авторы отмечают несколько простых способов автоматизации их тестирования вручную, а также некоторые инструменты, которые можно использовать с SQL Server. Со стороны Oracle гуру PL / SQL Стивен Фюрштайн работал над бесплатным инструментом модульного тестирования для хранимых процедур PL / SQL, который называется utPLSQL.

Однако он отбросил эти усилия, а затем стал коммерческим с Quest's Code Tester для PL / SQL. Квест предлагает бесплатную загружаемую пробную версию. Я нахожусь на грани попытки этого; Насколько я понимаю, хорошо позаботиться о дополнительных затратах при настройке инфраструктуры тестирования, чтобы вы могли сосредоточиться только на самих тестах, и она сохраняет тесты, чтобы вы могли использовать их в регрессионном тестировании, что является одним из больших преимуществ тест-привод развития. Кроме того, предполагается, что он хорош не только для проверки выходной переменной, но и для проверки изменений данных, но мне все же нужно присмотреться. Я думал, что эта информация может быть полезна для пользователей Oracle.

Answer 3

О, мальчик. sprocs не подходит для (автоматического) модульного тестирования. Я сортирую «модульное тестирование» моих сложных sprocs, записывая тесты в пакетных файлах t-sql и вручную проверяя вывод операторов print и результаты.

Answer 4

Один из вариантов перефакторинга кода (я допускаю уродливый взлом) состоит в том, чтобы сгенерировать его через CPP (препроцессор C) M4 (никогда не пробовал) или тому подобное. У меня есть проект, который делает именно это, и на самом деле он в основном работает.

Единственный случай, который, на мой взгляд, может быть действительным, это 1) как альтернатива хранимым процедурам KLOC + и 2) и это мои случаи, когда цель проекта - увидеть, как далеко (в безумие) вы можете подтолкнуть технология.

Answer 5

Мы тестируем модуль C #, который вызывает SP.
У нас есть скрипты сборки, создающие чистые тестовые базы данных.
И более крупные, которые мы прикрепляем и отсоединяем во время испытаний.
Эти тесты могут занять несколько часов, но я думаю, что это того стоит.

Answer 6

LINQ упростит это, только если вы удалите логику из ваших хранимых процедур и переопределите ее как запросы linq. Что было бы гораздо надежнее и проще для тестирования, безусловно. Однако, похоже, ваши требования помешают этому.

TL; DR: у вашего дизайна есть проблемы.