Здравствуйте, Ночной Смотрящий, Вы писали:

НС>И что ты там сможешь проверить? только сам факт вызова? А что насчет проверки самих скриптов?

Проверить ты сможешь идентичность структур БД полученных в следствии миграции и прямого создания БД. Сами скрипты и есть код миграции вызывающие АПИ миграции.

На фиг это нужно — спрашивай у автора темы.

НС>Вынужденное зло. Если ПР будет прогоняться часов 6 — это еще хуже.

Нет. Это будет лучше. У нас при таком уродском подходе ПР идет часа 3-4 (на адско быстром железе).

НС>Именно это я и написал.

Обычно это не так. Так как тесты очень ресурсоёмкие они гонятся не для каждого ПРа, а скопом. Например, в выходные, когда инфра не так загружена. И это вот вызывает дичайшие проблемы.

НС>С чем ты споришь?

Это ты споришь. Я всего лишь заметил, что при выборе между интеграционными и модельными нужно всегда выбирать последние. Так что если стоит выбор написать сложный мок или сделать менее сложный интеграционный тест нужно выбирать создание сложного мока. Иначе рано или поздно ты придешь вот к такому говниющу когда тесты идут хрен знает когда и найти ПР который привел к регрессу становится не самой простой задачей требующей много времени квалифицированных программистов. Время железа всегда дешевле времени людей.

Здравствуйте, VladD2, Вы писали:

НС>>И что ты там сможешь проверить? только сам факт вызова? А что насчет проверки самих скриптов?
VD>Проверить ты сможешь идентичность структур БД полученных в следствии миграции и прямого создания БД.

Для этого нужна либо реальная БД, либо интерпретатор SQL.

VD>Сами скрипты и есть код миграции вызывающие АПИ миграции.

API миграции это SQL, если ты не понял.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Для этого нужна либо реальная БД, либо интерпретатор SQL.

Для этого нужно реализовать функции миграции миграционного API.

НС>API миграции это SQL, если ты не понял.

Ты слишком примитивно мыслишь. API миграции это набор дотнетных функций, который должен привести к добрвлению, удалению колонок в таблицах и т.п. но к SQL они не обязаны иметь отношение. Как и любой API их можно замокать и вместо изменения структура БД менять некую метамодель. Далее остаётся сравнить эти метамодели и убедиться что эта модель созданная с помощью миграции аналогична модели созданной при создании БД.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>И что ты там сможешь проверить? только сам факт вызова? А что насчет проверки самих скриптов?

То что структура БД полученная при миграции, т.е. последовательных изменениях БД идентична структуре полученной созданием БД.

Тесты такие имеют смысл для тестирования самого API миграции. Зачем это автору я не понимаю. Но без моков такие тесты имеют не больше смысла для прикладных систем.

Здравствуйте, VladD2, Вы писали:

VD>Ты слишком примитивно мыслишь. API миграции это набор дотнетных функций, который должен привести к добрвлению, удалению колонок в таблицах и т.п.

Тебе в стартовом сообщении прямо написали — скрипты.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Тебе в стартовом сообщении прямо написали — скрипты.

Скрипты миграции — это не более чем последовательность вызовов API миграции. Вот здесь

Автор: Qulac
Дата: 05.04.23

автор темы показал псевдокод того, что он хочет видеть.

Здравствуйте, VladD2, Вы писали:

НС>>Тебе в стартовом сообщении прямо написали — скрипты.
VD>Скрипты миграции — это не более чем последовательность вызовов API миграции.

Это ты сам придумал. Автор написал совсем другое:

загонять скрипты в ms sql

Нет у ms sql никакого API миграций, есть DDL.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Это ты сам придумал. Автор написал совсем другое:

Меня эта резьба по цитатам и твои выдумки уже утомили. Верь во что хочешь. Тут есть автор. Можешь у него спросить и с ним поспорить.

Здравствуйте, VladD2, Вы писали:

НС>>Это ты сам придумал. Автор написал совсем другое:
VD>Меня эта резьба по цитатам и твои выдумки уже утомили.

Выдумки у тебя. Автор понятно написал что речь про скрипты сиквела, и все кто хотя бы чуток в теме понимают о чем речь, ибо задача неуникальная, мягко говоря. А ты тут носишься со своими моками, высасывая из пальца несуществующие факты, и еще обвиняешь в выдумках других. А когда тебя ткнули носом в то что ты, по своему обыкновению, с первого раза прочесть не смог — ты переключился на демагогию. С чем тебя и поздравляю.

Здравствуйте, Qulac, Вы писали:

Q> Цель — тестирование скриптов миграции не подымая для этого реальный сервер.

Здесь был бы очень уместен смайл "Мурзилка" — такой глупый чудик, который краем уха что-то слышал о тестировании, а потом в своих (очевидно, нубских) мечтах хочет, чтобы "ничего не работало, но всё тестировалось" У тебя что, компания из 1 эникейщика и ноутбука, где, цитирую, "не подымая для этого реальный сервер"?
Было бы куда уместнее (особенно в твоём случае) описать конкретную задачу, чем фонтанировать "абстрактными, глобальными идеями" (не имеющими реального воплощения) и зазря сталкивать профи на тупые споры (см. конец темы, куда ты даже носа не суёшь, ибо вообще не понимаешь, что обсуждают).
Не надо лезть в большие мыслители — как правило, все твои нубские проблемы уже давно решены, просто озвучь. За это и поставил минус, если интересно.

Здравствуйте, Qulac, Вы писали:

Q>Кто ни будь знает либу для этого? Нужно что бы она позволяла писать файлы, изменять реест, загонять скрипты в ms sql, но при этом ни чего не делала, а сохраняло все в памяти, что бы потом можно было сравнивать один объект окружения с другим. Цель — тестирование скриптов миграции не подымая для этого реальный сервер.
Эта "либа" называется Docker.
Если у вас с автоматизацией тестирования всё так плохо (по историческим причинам), то скриптуйте полный интеграционный цикл: стартуем виртуалку в заданном начальном состоянии, натравливаем на неё скрипт миграции, проверяем результат, удаляем виртуалку. Rinse, repeat.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Qulac, Вы писали:

Q>>Кто ни будь знает либу для этого? Нужно что бы она позволяла писать файлы, изменять реест, загонять скрипты в ms sql, но при этом ни чего не делала, а сохраняло все в памяти, что бы потом можно было сравнивать один объект окружения с другим. Цель — тестирование скриптов миграции не подымая для этого реальный сервер.
S>Эта "либа" называется Docker.
S>Если у вас с автоматизацией тестирования всё так плохо (по историческим причинам), то скриптуйте полный интеграционный цикл: стартуем виртуалку в заданном начальном состоянии, натравливаем на неё скрипт миграции, проверяем результат, удаляем виртуалку. Rinse, repeat.

У нас есть уже готовый протестированный инстанс новой версии, которая уже прошла последнею стадию ручного тестирования. Есть скрип миграции со старой версии на новую. Т.е. у нас в итоге есть два инстанса один получился при установке программы, второй при обновлении. Как их легко и просто сравнить и чем мне здесь поможет докер? Хочется иметь способ близкий к этому:

//сравниваем окружение после установки и после миграции
Assert.AreEqual(enviromendNew,enviromendMigration)

что бы не писать каждый раз в тестах сравнение каждой закорючки.

Здравствуйте, Qulac, Вы писали:

Q>У нас есть уже готовый протестированный инстанс новой версии, которая уже прошла последнею стадию ручного тестирования. Есть скрип миграции со старой версии на новую. Т.е. у нас в итоге есть два инстанса один получился при установке программы, второй при обновлении. Как их легко и просто сравнить и чем мне здесь поможет докер?
Вкратце — никак. Ваш вопрос чем-то похож на "я заехал в болото на ламборджини. Как мне теперь выехать оттуда, не применяя внешних средств?". Правильный ответ — "не заезжать в болото на ламборджини".

Если вам хочется поразвлекаться, то можете попробовать изолировать важную для вас часть окружения.
То есть, скажем, монтируете фолдеры ФС, которые подлежат миграции, в отдельные тома. После миграции выполняете побайтное сравнение этих томов с заданными.
Состояние базы дампите в виде SQL-скрипта, посимвольно сравниваете этот скрипт с образцом.

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

Я бы попробовал сосредоточиться на написании генератора "проверок", который на основе скриптов развёртывания инстанса новой версии порождает скрипты, проверяющие результат развёртывания/миграции.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Qulac, Вы писали:

Q>>У нас есть уже готовый протестированный инстанс новой версии, которая уже прошла последнею стадию ручного тестирования. Есть скрип миграции со старой версии на новую. Т.е. у нас в итоге есть два инстанса один получился при установке программы, второй при обновлении. Как их легко и просто сравнить и чем мне здесь поможет докер?
S>Вкратце — никак. Ваш вопрос чем-то похож на "я заехал в болото на ламборджини. Как мне теперь выехать оттуда, не применяя внешних средств?". Правильный ответ — "не заезжать в болото на ламборджини".

S>Если вам хочется поразвлекаться, то можете попробовать изолировать важную для вас часть окружения.
S>То есть, скажем, монтируете фолдеры ФС, которые подлежат миграции, в отдельные тома. После миграции выполняете побайтное сравнение этих томов с заданными.
S>Состояние базы дампите в виде SQL-скрипта, посимвольно сравниваете этот скрипт с образцом.

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

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

S>Я бы попробовал сосредоточиться на написании генератора "проверок", который на основе скриптов развёртывания инстанса новой версии порождает скрипты, проверяющие результат развёртывания/миграции.
А вот об этом стоит поразмыслить.