Как вы тестируете свой T-SQL? Какие библиотеки / инструменты вы используете?
Посмотрите на TSQLUnit и tSQLt .
Я экспериментировал с использованием нескольких различных фреймворков на многих языках для тестирования T-SQL, таких как junit или nunit. Причина, по которой я пошел по этому пути, заключалась в том, чтобы воспользоваться преимуществами богатой среды тестирования на этих других языках. Например, если вы используете nunit, у него есть хорошая командная строка и программа просмотра графического интерфейса для просмотра состояния ваших тестов, а поскольку вы используете .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% только потому, что в большинстве систем баз данных исторически не было тестов, созданных для них, поскольку они были созданы, поэтому я нахожусь в процессе ретроспективного активного добавления тестов и добавления тестов по мере появления новых дефектов и улучшений.
Считаете ли вы, что время и усилия, которые вы вложили в проводку для модульного тестирования, окупились или нет?
База данных - это хлеб и масло большинства предприятий. Это всегда окупается на мой взгляд. Если ваш бизнес терпит нежелательные и высокие показатели отказов для клиента, то никакое тестирование, вероятно, не стоит, так как оно не бесплатное.
Если вы не используете модульное тестирование, можете ли вы объяснить, почему нет?
Я буду рад видеть, если кто-нибудь придумает ответ на этот вопрос, который не абсурден. Вроде как, почему бы вам не посадить своего ребенка в автокресло при езде по дороге ... "Они стоят слишком дорого" ... "Занимает слишком много времени, чтобы посадить ребенка" .. "Без него он в безопасности ".." Что может пойти не так, чтобы оправдать это ".." Просто не хватает времени "Все это бз.
Да, я знаю, что, может быть, немного экстрима, но на самом деле, если у вас есть система, которая приносит ценность компании, ее следует объединить, чтобы выявить некоторые проблемы, прежде чем они станут проблемами производства. Модульное тестирование не является панацеей, но это один из инструментов, который мы должны сделать, как можем.
В целом, я бы сказал, что большинство людей предоставляют базе данных бесплатный проход, когда речь идет о структурном тестировании. Я понятия не имею, почему это так, но я видел это в компании за компанией. Я бы хотел увидеть это изменение.