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

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

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

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

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

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

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

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

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

ЗЫ

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

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

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

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

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

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

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

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

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

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

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

ЗЫ

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

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