Как делают Вас модульный тест Ваш T-SQL

Как вы проводите модульное тестирование T-SQL? Какие библиотеки/инструменты вы используете?

Посмотрите на TSQLUnit и tSQLt.

Я экспериментировал с использованием нескольких различных фреймворков на разных языках для тестирования T-SQL, таких как junit или nunit. Причина, по которой я пошел по этому пути, заключалась в том, чтобы воспользоваться преимуществами богатых сред тестирования в этих других языках. Если, например, вы используете nunit, то у него есть хорошая командная строка и gui viewer для просмотра состояния ваших тестов, а поскольку вы используете .net для написания тестов, он легко подключается к sql-серверу. JUnit имеет хорошую интеграцию со многими коммерческими и открытыми средами IDE, такими как NetBeans и IDEA, а также делает тестирование T-SQL более похожим на тестирование Java-кода, что очень удобно. Отрицательным моментом является то, что вы не только пишете T-SQL, но и пишете java или .net для тестирования вашего T-SQL.

Я также использовал Ruby с Rake (это как make или ant) и делал системные вызовы sqlcmd для выполнения sql скриптов, которые в свою очередь содержали тесты. Скрипты возвращали значения и строки обратно в Ruby, чтобы пройти или провалить тест. Этот подход мне понравился больше всего, так как он был очень простым и легким для других. Другие вышеупомянутые пути требовали от разработчиков использования .net или java, что, если у вас все DBA-типы, может быть трудно преодолеть, в то время как подход ruby с sql-скриптами, по моему опыту, легче продать. Типы DBA, как правило, открыты и способны легко освоить скриптовые языки, а Ruby имеет низкую кривую обучения, и скрипты легко запускаются по сравнению с классами .net или java.

Какой процент вашего кода покрыт модульными тестами и как вы его измеряете?

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

Как вы думаете, окупилось ли время и усилия, которые вы вложили в ваш набор для модульного тестирования?

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

Если вы не используете модульное тестирование, можете ли вы объяснить, почему?

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

Да, я знаю, что это немного экстремально, но действительно, если у вас есть система, и она приносит компании пользу, она должна быть объединена в единое тестирование, чтобы помочь отловить некоторые проблемы до того, как они станут производственными проблемами. Единичное тестирование - это не панацея, но это один из инструментов, с помощью которого мы можем сделать все возможное.

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