Кто ни будь знает либу для этого? Нужно что бы она позволяла писать файлы, изменять реест, загонять скрипты в ms sql, но при этом ни чего не делала, а сохраняло все в памяти, что бы потом можно было сравнивать один объект окружения с другим. Цель — тестирование скриптов миграции не подымая для этого реальный сервер.

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

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

Не бывает.

Ну или виртуалки и чудовищный набор скриптов

А как ты себе это представляешь чисто теоретически?
Это же нужно перехватить все вызовы типа File.Read/Write, Registry.Read/Write + db-провайдеры. В теории возможно, конечно, но на на практике проще виртуалку поднять или через docker/podman-compose окружение развернуть.

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

RD>А как ты себе это представляешь чисто теоретически?
RD>Это же нужно перехватить все вызовы типа File.Read/Write, Registry.Read/Write + db-провайдеры. В теории возможно, конечно, но на на практике проще виртуалку поднять или через docker/podman-compose окружение развернуть.

Это может быть объект типа Environment, который передается скрипту при миграции и только через него скрипт работает. В тестах мы используем имитацию этого объекта, главное что бы можно было сравнивать состояние подобным образом:

Assert.AreEqual(environment1,environment2)

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

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

как вариант , тестировать на одной машине под разными пользователями

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

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

Замокать все нужные АПИ. Это если под скриптами понимается дотнетный код.

VD>Замокать все нужные АПИ. Это если под скриптами понимается дотнетный код.

Это как бы очевидный вариант. Но в контексте тестирования SQL-скриптов миграции, имхо бесполезный.
Индексы, триггеры, sequences, reference/check constraints и т.п. так не проверишь, как и особенности реальных данных не учтешь.

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

RD>Это как бы очевидный вариант. Но в контексте тестирования SQL-скриптов миграции, имхо бесполезный.
RD>Индексы, триггеры, sequences, reference/check constraints и т.п. так не проверишь, как и особенности реальных данных не учтешь.

Желание протестировать все сразу — это интеграционные тесты. Он намного сложнее и дороже. По этому люди стараются тестировать не весь продукт сразу, а его отдельные компоненты. Если ты тестируешь систему миграции, не нужно тестировать БД. Для тестирования БД лучше создать отдельные, изолированные тесты. Вот и автор пишет:

Нужно что бы она позволяла писать файлы, изменять реест, загонять скрипты в ms sql, но при этом ни чего не делала, а сохраняло все в памяти, что бы потом можно было сравнивать один объект окружения с другим. Цель — тестирование скриптов миграции не подымая для этого реальный сервер.

Цель автора темы — изолированное тестирование одного компонента — скриптов миграции. Следовательно они не должны непосредственно управлять файлами, БД и реестром. Весь доступ к ним должен быть изолирован. Для этого нужно ввести слои абстракции, которые и будут общаться с системами ввода-вывода. Для пишем моки, которые эмулируют работу реальных компонентов и, например, пишут логи. А далее эти логи можно сравнить с неким образцом. Ну или моки формируют объекты в памяти, которые опять таки с чем-то сравниваются.

VD>Цель автора темы — изолированное тестирование одного компонента — скриптов миграции.

Я не отрицаю пользу юнит-тестов.
Но, как мне кажется, если бы у автора все сводилось к тому, чтобы обложиться моками и тестироваться в изоляции, то и вопрос бы не возник.
Однако, на мой взгляд фраза `загонять скрипты в ms sql` предполагает, что скрипты все-таки должны исполняться движком БД.
И замокав эту часть, максимум что можно будет проверить — это порядок накатки и тот факт, что текст отправленных в БД команд совпадает с каким-то эталоном.
Но, если, например в скрипте вместо CREATE TABLE будет написано CREAT TABLE, то 99% что unit-тест такое не поймает.

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

VD>Цель автора темы — изолированное тестирование одного компонента — скриптов миграции. Следовательно они не должны непосредственно управлять файлами, БД и реестром. Весь доступ к ним должен быть изолирован. Для этого нужно ввести слои абстракции, которые и будут общаться с системами ввода-вывода. Для пишем моки, которые эмулируют работу реальных компонентов и, например, пишут логи. А далее эти логи можно сравнить с неким образцом. Ну или моки формируют объекты в памяти, которые опять таки с чем-то сравниваются.

Дело не только в моках, а в сравнении состояния моков, хочется иметь что-то похожее на это:

//получаем окружение после установки старой версии
var enviromentOld = new Install().Up(new Enviroment());

//получаем окружение после установки новой версии
var enviromendNew = new Install().Up(new Enviroment());

//получаем окружение после миграции со старой на новую версию
var enviromendMigration = new Migration().Up(enviromentOld);

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

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

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

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

Самый легковесный вариант — поднимать все в контейнере. Более дорогой — поднимать виртуалку.

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

Q>Я понимаю, тут есть тонкости не всегда новая версия после инсталляции полностью равна версии полученной входе миграции,

Скорее чаще не равна, так как новая БД не содержит данных, а старая почти наверняка содержит.

Q>но можно использовать какие ни будь настройки для сравнения окружений, что бы подобные вещи учесть. Делать это вручную на моках — много писанины, что чревато ошибками, плюс при изменении способа развертывания их нужно будет изменять, дополнять и т.д. Хотелось бы иметь решение в общем виде.

У тебя выбор особо не велиК.

1. Ты делаешь полноценные интеграционные тесты и сравниваешь реальные сущности. Например, после миграции на реальной СУБД получаешь скрипты создания сущностей и сравниваешь их. Тут, как тебе рядом совершенно правильно подсказали, можно использовать виртуалки и т.п.

2. Ты делаешь моки, которые позволяют тебе получить метаданные описывающие новое состояние системы без использования СУБД и т.п. Моки могут формировать некоторые структуры в памяти, например, описывающие метаданные СБУД (таблицы, индексы и т.п.). Далее останется сравнить эти объекты полученные от миграции и от создания БД (как у тебя в псевдокоде).

Путь два несомненно сложнее. Но зато он позволит вам прогонять тесты быстрее и получать куда более стабильные тесты. А это главное.

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

ЗЫ

Создаётся полное ощущение, что вы тестируете не свою зону ответственности. По идее за соответствие миграции и создания БД должен отвечать соответствующий фрэймворк. У него должны быть свои авторы и свои тесты. Вы точно не занимаетесь чужой работой?

Зачем вы тестируете движок миграции? Таким Макаром можно еще Виндовс протестировать или SQL-сервер.

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

НС>Самый легковесный вариант — поднимать все в контейнере. Более дорогой — поднимать виртуалку.

Это будут интеграционные тесты со всеми вытекающими проблемами.

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

НС>>Самый легковесный вариант — поднимать все в контейнере. Более дорогой — поднимать виртуалку.
VD>Это будут интеграционные тесты со всеми вытекающими проблемами.

Так там из исходных требований это следует, вне зависимости от того как это реализовывать. Для юнит/компонентных нужны моки, не только для легковесности, но и для контроля.

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

VD>2. Ты делаешь моки, которые позволяют тебе получить метаданные описывающие новое состояние системы без использования СУБД и т.п.

Сделать для БД мок, проверяющий скрипты миграции — no way.

VD>На мой взгляд тест не ходящий на ПР-е это зло. \

ПР разные бывают. К примеру, ПР в стори ветку, ПР в мастер, ПР в релизную ветку. И все равно есть тесты, которые на любой ПР слишком дорого. Их обычно гоняют по расписанию.

VD>Создаётся полное ощущение, что вы тестируете не свою зону ответственности. По идее за соответствие миграции и создания БД должен отвечать соответствующий фрэймворк. У него должны быть свои авторы и свои тесты.

Теоретически. А на практике знал бы ты, сколько раз и какое количество времени мне спасли хотя бы минимальные тесты на внешние зависимости.

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

VD>>Это будут интеграционные тесты со всеми вытекающими проблемами.

НС>Так там из исходных требований это следует, вне зависимости от того как это реализовывать. Для юнит/компонентных нужны моки, не только для легковесности, но и для контроля.

Нет из исходных требований это не следует. Исходные требования как раз говорят о том, что изменения БД и файлов быть не должно:

Нужно что бы она позволяла писать файлы, изменять реест, загонять скрипты в ms sql, но при этом ни чего не делала, а сохраняло все в памяти, что бы потом можно было сравнивать один объект окружения с другим.

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

НС>Сделать для БД мок, проверяющий скрипты миграции — no way.

Мок нужно делать не для БД, а для библиотеки миграций. И это не очень сложно.

НС>все равно есть тесты, которые на любой ПР слишком дорого. Их обычно гоняют по расписанию.

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

На мой взгляд лучше все тесты гнать на ПРе, а те что долгие просто гнать как-бы после заезда ПРа. Ну или надо делать систему, которая будет искать ПР в котором появилась ошибка. Иначе это приводит к сильным непроизводительным затратам. А учитывая, что тесты (особенно интеграционные) могут флакать — это превращается вообще в недетерминированное действо и кашмар.

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

НС>Теоретически. А на практике знал бы ты, сколько раз и какое количество времени мне спасли хотя бы минимальные тесты на внешние зависимости.

Тесты на внешние зависимости, они же интеграционные тесты, несомненно нужны. Но их должно быть минимум, так как они по определению самые медленные и самые ненадежные (особенно если проверяется интеграция с внешними сервисами).

У нас, например, тоже не выходит гнать все тесты на каждом ПРе. К тому же наши залудили Монорепу и в результате в мастер лезут комиты от разных продуктов, а иногда и не от продуктов вовсе. По этому придумнны разные BvtPvt и Smoke, которые идут совершенно независимо от ПРов. Баги с них могут завестись получить третий приоритет и по несколько месяцев висеть без разбора. А потом такое говно сваливается на тебя и ты занимаешься не отладкой, а игрой в Шерлока Холмса расследуя случившееся. В результате фикс баги вместо нескольких часов превращается в день или многодневный неблагодарный труд.

Наверно если ты делаешь сайт командой в 10 человек, это не особая проблема. Но когда в разработку вовлечены хотя бы сотни людей — это еще та боль.

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

VD>Нет из исходных требований это не следует. Исходные требования как раз говорят о том, что изменения БД и файлов быть не должно:

Там заявлена полноценная работа со всем окружением — ФС, БД, реестр. Это интеграционные тесты.

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

НС>>Сделать для БД мок, проверяющий скрипты миграции — no way.
VD>Мок нужно делать не для БД, а для библиотеки миграций. И это не очень сложно.

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

НС>>все равно есть тесты, которые на любой ПР слишком дорого. Их обычно гоняют по расписанию.
VD>Вот это и есть зло.

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

VD>На мой взгляд лучше все тесты гнать на ПРе, а те что долгие просто гнать как-бы после заезда ПРа.

Именно это я и написал. С чем ты споришь?

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

НС>Там заявлена полноценная работа со всем окружением — ФС, БД, реестр. Это интеграционные тесты.

Где, там? Прочитай еще раз и попытайся процитировать, что ты там увидел. Человек рядом даже привел псевдокод и явно сказал, "ни чего не делала", что я тебе уже два раза процитировал. Но ты упорно стоишь на своём.

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

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

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

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

НС>Вынужденное зло. Если ПР будет прогоняться часов 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>Я бы попробовал сосредоточиться на написании генератора "проверок", который на основе скриптов развёртывания инстанса новой версии порождает скрипты, проверяющие результат развёртывания/миграции.
А вот об этом стоит поразмыслить.