Обновить
0
0

Пользователь

Отправить сообщение
Прийти можно разными путями
— согласен.
Одинаковый результат по выживанию
— нет. Пессимистов доберется больше. Хотя нужны и те и другие. (Я про эволюцию)
Консерваторы против революционеров. Еще очко в пользу консерваторов.
Кто в молодости не был радикалом — у того нет сердца, кто в зрелости не стал консерватором — у того нет ума. (Вроде Дизраэли)
Я всегда следовал правилу: не беги, если можешь стоять; не стой, если можешь сидеть; не сиди, если можешь лежать. (Черчилль)

В Visual Studio, проект SSDT имеется SQL Server Unit Test template, библиотека Microsoft.Data.Tools.Schema.Sql.UnitTesting
За исключением fake tables, описанная Вами функциональность там имеется. Для заполнения и откатки данных используются пре- и пост- скрипты. GUI по аналогии с WinForms — код на TSQL как «визуализация» и код на C# как возможность расширения. Пользуюсь больше 10и лет, очень доволен.
Спасибо, Ваш подход радует. Я ни в коей мере не скептик. Как только в Райдере будет ВЕСЬ или хотя бы бОльшая часть нужного мне функционала, я буду рад перейти. Дайте мне отладку всей цепочки от клиента в БД плюс CLR и поддержку специфических плюшек MSSQL, генерацию апгрейдов и возможность управления игнорами как в SSDT и я ваш навеки :)
:)
Я думал об этом, но идеология ДатаГрипа мне не нравится — он работает с коллективом скриптов, а не проектом. Кроме того, CLR и проч и проч, о чем писал выше. Кроссплатформенность для меня не актуальна. 64бит — да, мечта, но только ради этого я из студии не уйду. А еще BI, SSAS, Workflow…
И вообще, писать на шарпе в среде джавы как-то некузяво :))
Если серьезно, адд-он к студии я бы купил, как и решарпер.
Мне, как пользователю связки MSSQL/C# — VisualStudio, в первую очередь НЕ хочется ставить дополнительную среду для девелопмента базы данных — это около 70% моего времени. Дебаг, в том числе CLR, в том числе вместе с вызовом из клиента на С#, деплой в разные среды, юнит-тесты. Если будет удобный адд-он в студию, как и сам SSDT, лично я, возможно, и перейду на него, если будет edit value против SSDT. Лично мне там не хватает рефакторингов, поддержки репликации и настроек деплоя.
Я знаю :) Вот и говорю «да» решарперу и «нет» грипу. Он общий и с другой парадигмой. У меня нет светлой мечты «а завтра я хочу все тоже, но на ...» Меня устраивает продукт, заточенный конкретно под MSSQL. А когда пишется общее решение, то теряются детали, как то CLR, Service Broker…
Решарпер юзаю, но это другая парадигма, мне с ними не по пути
SSDT да, еще не мертв, но и жив как-то странно. Сообщества мертвые. В принципе, поддержка идет на уровне самого MS SQL ака поддержка новых версий и фич. Чтобы похоронить, нужен другой продукт, а им и не пахнет. На конфлоктах да, терять можно, но очень специфические вещи — например, схема трансфер+partitioning — на этом разруливал ручками. А сгенеренные скрипты я проверяю всегда, ну и бэкап пока не отменили ;)))
Тем не менее, лучшего продукта для MSSQL нет. По совокупности.
У меня на последней работе — 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? Я сам-то умру такое сравнивать/мержить, а уж убедить всю команду так делать… Только если действовать как Каа на бандерлогов, но у меня дар убеждения так не прокачан.» Ну, я живу, хотя с таким способом хранения, да, сравнивать не просто. Но не помню, чтобы приходилось. По поводу Каа — тут согласен полностью, мне тоже команду убедить не удалось. Но тех, кого заставил, довольны.
В SSDT юнит тест это класс с пре- (создать данные), пост-(снести данные) events и самим тестом (со встроенными проверками — непустой рекордсет, количество записей, значение и тд). Вы можете писать как обычнйый TSQL, так и вызов объектов базы (процедуры). Имеется app.config, где настраивается соединение, терсты не обязаны бежать на сервере. MS Build это поддерживает, так же сами тесты могут использовать стандартные asserts.
Вам удалось придумать нечто очень похожее на SQL Unit Test Project в SSDT
Лично я им пользуюсь около десятка лет, советую посмотреть.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность