Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 24

Вам удалось придумать нечто очень похожее на SQL Unit Test Project в SSDT
Лично я им пользуюсь около десятка лет, советую посмотреть.
Комментарий пока не оценивали0
SQL Server Unit Test содержит процедуры подоговки и очистки тестирования.
Это совсем не то.

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

Не используется и VS мне иногда надо запускать тесты на удаленной машине, где доступен только sqlcmd.
Комментарий пока не оценивали0
В SSDT юнит тест это класс с пре- (создать данные), пост-(снести данные) events и самим тестом (со встроенными проверками — непустой рекордсет, количество записей, значение и тд). Вы можете писать как обычнйый TSQL, так и вызов объектов базы (процедуры). Имеется app.config, где настраивается соединение, терсты не обязаны бежать на сервере. MS Build это поддерживает, так же сами тесты могут использовать стандартные asserts.
Комментарий пока не оценивали0
Это этого я и ушел, причины описал сверху.

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

SSDT — прекраснейшая по задумке штука (отделить разработку кода от живой БД — это супер, иметь нормальные code references и рефакторинг — почти бесценно). И для небольших решений подходит, наверное. Но для сколько-то крупных решений это сплошная мука. Вот кратко только то обо что совсем больно спотыкаться.


  • Разработка решений из нескольких БД/серверов.
  • Разработка нескольких БД у которых существенная общая часть кода.
  • Разработка БД больше 1000 объектов (сколько будет собираться решение?).
  • Разработка БД для нескольких разных версий СУБД.
  • Разработка с объектами уровня сервера.
  • Мелочь, а всё-таки, сборка проектов с enterprise фичами.

Модульные тесты SSDT это просто соседнее решение почти обычных UT, которое можно прикрутить к сборке SSDT. Не то чтобы это совсем плохо, но получается достаточно узкая применимость. Навскидку:


  • Это C# решение, а значит надо, чтобы разработчик базово умел C#.
  • Сборка под виндой (что уже ограничение), плюс headless сборка SSDT — это та еще румба с бубном.
  • Тесты хранятся в интерактивно меняемых resx. Как с этим жить с git? Я сам-то умру такое сравнивать/мержить, а уж убедить всю команду так делать… Только если действовать как Каа на бандерлогов, но у меня дар убеждения так не прокачан.
  • В отличие, например, от tSQLt, у которого кишки нормально спрятаны, у модульных тестов SSDT все кишки разложены в решении. Это лишняя когнитивная нагрузка на разработчика, задача которого "просто написать юнит-тест" прямо сейчас.

Но, повторюсь, если у вас всего объектов <500 и есть еще логика на C#, если всё лежит в одной БД, у которой нет ни вызовов master/msdb, ни вызовов linked server'ов, ни передачи данных из ХП в ХП через временные таблицы, нет требований по автоматизации сборки, то, конечно, попробовать стоит.

Комментарий пока не оценивали0
У меня на последней работе — solution из 12 баз с общими блоками — использую composite projects. Более 1000 обектов наверняка, имеется репликация, CLR, Service Broker. Используются master и msdb, Даже есть CLR, которые использует данные из темп таблицы ;). Линкед серверов нет, да и при использовании референсед баз они как бы появляются сами по себе. Компиляция, да, больное место, минуты 3-4, 32ГБ памяти. Обекты уровня сервера поддерживаются, я использовал логины, триггеры на БД, signatures, asymmetric keys и master keys.
«Это C# решение, а значит надо, чтобы разработчик базово умел C#» Полезно, но необязательно, можно все делать в гуях
«Сборка под виндой (что уже ограничение), плюс headless сборка SSDT — это та еще румба с бубном» Тут соглашусь, настройка деплоя еще тот праздник. Но, с другой стороны, за возможность НЕ писать апрейды на каждую версию я все готов простить.
«Тесты хранятся в интерактивно меняемых resx. Как с этим жить с git? Я сам-то умру такое сравнивать/мержить, а уж убедить всю команду так делать… Только если действовать как Каа на бандерлогов, но у меня дар убеждения так не прокачан.» Ну, я живу, хотя с таким способом хранения, да, сравнивать не просто. Но не помню, чтобы приходилось. По поводу Каа — тут согласен полностью, мне тоже команду убедить не удалось. Но тех, кого заставил, довольны.
Всего голосов 1: ↑1 и ↓0+1

На предыдущем месте работы проекты в 500 таблиц (и гора SP, UDF и т.п., понятно) собирались минут 10-20, "большой" проект на 2000 таблиц (и 6000 кажется всего объектов) собирался больше часа на 16 ГБ. После перехода на SSD "всего" 30 минут. Плюс там регулярно 32-битная VS начинает утыкаться в лимит памяти. Если несколько таких проектов зависят друг от друга, то это адский мрак. Короче, формировать адский файл модели данных в XML (это он при компиляции и разборе проекта делает) было не самой лучшей архитектурной идеей.
Мне правда SSDT понравился, и, правда, я не тот кто "просто не умеет готовить", но на наших решениях перейти не получилось.


Кстати, в апгрейдах есть еще одна засада. В SSDT очень легко при разруливании merge conflict потерять историю рефакторинга и вместо аккуратной трансформации таблицы получить "оопс".


Причем обидно, что уже лет 5 SSDT в развитии практически замер (ну или мне так кажется). Если MS его похоронит, будет печаль.

Комментарий пока не оценивали0
SSDT да, еще не мертв, но и жив как-то странно. Сообщества мертвые. В принципе, поддержка идет на уровне самого MS SQL ака поддержка новых версий и фич. Чтобы похоронить, нужен другой продукт, а им и не пахнет. На конфлоктах да, терять можно, но очень специфические вещи — например, схема трансфер+partitioning — на этом разруливал ручками. А сгенеренные скрипты я проверяю всегда, ну и бэкап пока не отменили ;)))
Тем не менее, лучшего продукта для MSSQL нет. По совокупности.
Комментарий пока не оценивали0

Лично я очень надеюсь, что дозреет DataGrip от JetBrains (правда, moscas ?), но пока они сосредоточены на немного другой модели работы разработчика.

Комментарий пока не оценивали0
Решарпер юзаю, но это другая парадигма, мне с ними не по пути
Комментарий пока не оценивали0
Не-не-не. Решарпер и DataGrip — два разных продукта. Прям вообще разных. И команда разная, и технологии разработки разные и идеология разная.
Комментарий пока не оценивали0
Я знаю :) Вот и говорю «да» решарперу и «нет» грипу. Он общий и с другой парадигмой. У меня нет светлой мечты «а завтра я хочу все тоже, но на ...» Меня устраивает продукт, заточенный конкретно под MSSQL. А когда пишется общее решение, то теряются детали, как то CLR, Service Broker…
Всего голосов 1: ↑1 и ↓0+1
Вообще, это не противоречие, специфические для вендора детали мы тоже поддерживаем. Но на данной стадии нечасто, все еще много «общего», что предстоит сделать. Управление коннекциями, миграция базы, удобный алгоритм работы с VCS, сравнение схем – это все не вендор-специфично.
Всего голосов 1: ↑1 и ↓0+1
Мне, как пользователю связки MSSQL/C# — VisualStudio, в первую очередь НЕ хочется ставить дополнительную среду для девелопмента базы данных — это около 70% моего времени. Дебаг, в том числе CLR, в том числе вместе с вызовом из клиента на С#, деплой в разные среды, юнит-тесты. Если будет удобный адд-он в студию, как и сам SSDT, лично я, возможно, и перейду на него, если будет edit value против SSDT. Лично мне там не хватает рефакторингов, поддержки репликации и настроек деплоя.
Всего голосов 1: ↑1 и ↓0+1
Так наша цель, чтобы вы использовали Rider со встроенным туда ДатаГрипом =)
Всего голосов 1: ↑1 и ↓0+1
:)
Я думал об этом, но идеология ДатаГрипа мне не нравится — он работает с коллективом скриптов, а не проектом. Кроме того, CLR и проч и проч, о чем писал выше. Кроссплатформенность для меня не актуальна. 64бит — да, мечта, но только ради этого я из студии не уйду. А еще BI, SSAS, Workflow…
И вообще, писать на шарпе в среде джавы как-то некузяво :))
Если серьезно, адд-он к студии я бы купил, как и решарпер.
Всего голосов 1: ↑1 и ↓0+1
Про первое мы думаем, как раз концепция SSDT кажется симпатичной. Мы точно будем реализовывать что-то похожее.
Адд-он к студии мы делать не будем, у нас есть, вероятно, лучшая в мире платформа, которая позволяет нам быстро делать крутые штуки. И мы верим, что крутость этих штук так или иначе должна когда-нибудь зацепить даже самых ярых скептиков.
Всего голосов 1: ↑1 и ↓0+1
Спасибо, Ваш подход радует. Я ни в коей мере не скептик. Как только в Райдере будет ВЕСЬ или хотя бы бОльшая часть нужного мне функционала, я буду рад перейти. Дайте мне отладку всей цепочки от клиента в БД плюс CLR и поддержку специфических плюшек MSSQL, генерацию апгрейдов и возможность управления игнорами как в SSDT и я ваш навеки :)
Всего голосов 2: ↑2 и ↓0+2
Правда :) Понятно, что в перспективе мы должны дозреть до всего, но юнит-тестирование не в наших планах на ближайший год.
Недавно мы познакомились с Себастьяном, который делает tSQLt.org, и если будут мысли в этом направлении, может, начнем с него. С автором utplsql мы тоже знакомы, он использует DataGrip.

Но, повторюсь, пока есть более приоритетные задачи. И вы о них знаете :)
Всего голосов 1: ↑1 и ↓0+1
для Oracle используем в работе utplsql.
чем не угодил sourceforge.net/projects/uttsql?
бегло проглядел документацию — с виду аналогичет utplsql.

из коробки
— действия до/после теста или всего пакета
— html файлик отчета
— запускается просто вызовом соотв. функции. (то есть подходит для запуска из консоли БД)
Комментарий пока не оценивали0
Опять же в базе нужно создавать обьекты, тестировочный фрейворк, свой язык написания.
Это опять не то что я хотел. Все существующие тестировочные фрейворки (из тех что я вижу) предлагают ООП подход и классическую структуру тестов.

В статье я попытался от нее уйти.
Комментарий пока не оценивали0
Здравствуйте!

Вы пробовали sqitch? Я не являюсь специалистом по SQL БД и тестированию, поэтому мне он кажется замечательным. Интересно было бы услышать мнение более опытного специалиста.
Комментарий пока не оценивали0
А причем тут модульное тестирование? Это, как я понял, скорее конкурент всяким flyway/liquibase.
Комментарий пока не оценивали0
Да, я «немного» ошибся. В принципе делать тесты можно, конечно, через verify скрипты, но это не совсем то.

Я применяю sqitch в связке с pgTap, поэтому в сознании у меня два инструмента смешались — не мыслю одного без другого.
Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr