Как проверить миграцию баз данных?

Я использую Migrator.NET для записи миграции баз данных для приложения. Marc-André Cournoyer писал (а):

Как и любой код в вашем приложении, вы должен проверить ваши миграции. Коды вверх и вниз. Сделайте это частью своего непрерывный процесс сборки и тестирование на множестве различных баз данных и как вы можете.

Как мне это сделать? Скажем, у меня есть метод Up(), который создает таблицу и метод Down(), который удаляет одну и ту же таблицу, и я использую SQL Server. Как будет выглядеть тест? Должен ли я запускать SQL-запрос к системным таблицам, например select * from sys.columns, чтобы проверить, была ли создана таблица и что у нее правильная структура? Что делать, если мы используем NHibernate?

ИЗМЕНИТЬ Я имею в виду миграцию в смысле Rails ActiveRecord Migrations (создание, изменение и отключение баз данных небольшими шагами на основе кода С#).

РЕДАКТИРОВАТЬ 2 И здесь, где я читал о том, что мы должны тестировать миграции. Сообщение в блоге фактически связано с вики-версией Migrator.

Ответ 1

Вы тестируете свой DAL - какой-то тест интеграции?

Вам нужно больше, чем миграция script, вам также понадобится базовый уровень script. Если вы хотите протестировать обновление базы данных, вы должны запустить все сценарии из базовой линии на сервере тестирования/промежуточного уровня, чтобы создать самую новую версию базы данных. Затем проверьте свой DAL на актуальную тестовую базу данных. Если все тесты DAL преуспевают, ваша миграция должна быть успешной (в противном случае ваши тесты DAL недостаточно полны).

Это дорогостоящий тест для запуска, но он в значительной степени прочный. Я лично признаюсь, что сейчас делаю это вручную; у нас есть собственный инструмент миграции, который будет применять все сценарии (включая базовую линию), поэтому тестовая база данных и тесты DAL являются отдельными шагами. Это работает. Если вы хотите убедиться, что таблица была создана, нет лучшего способа, чем на самом деле попытаться вставить в нее данные!

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

Ответ 2

Элемент управления источником предназначен для моментального снимка текущей базы кода. Миграция предназначена для перемещения вашей базы данных с одной версии на другую. Чтобы в какой-то момент вы могли взять старую базу данных, применить миграцию и работать с последней базой кода.

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

describe User do
  it { should have_column :name, :type => :string }
  it { should validate_presence_of :name}       
end

Итак, кто-то меняет модель. Добавляет тест для отражения модели. Добавляет миграцию. Затем фиксирует источник.
Вы захватываете последние тесты. Тесты терпят неудачу, потому что база данных не соответствует. Вы не забыли запустить миграцию, а затем повторить тесты. Успех.

Ответ 3

Рассматривайте тестирование миграции как часть общей стратегии тестирования настойчивость при использовании NHibernate, то есть если вы можете создавать и сохранять все свои объекты без каких-либо ошибок, ваша база данных и ваши сопоставления должны быть правильными.

Ответ 4

Возможно, этот скрипт может помочь вам:

http://www.benzzon.se/forum/uploads/benzzon/2006-03-27_134824_sp_CompareDB.txt

this script сравнить два db. (структура и данные)

Ответ 5

Вы МОЖЕТЕ провести сравнение объектов системы баз данных, но вам нужно будет иметь цель, с которой следует сравнивать - в противном случае, как вы знаете, были ли они пройдены или не удались?

Я думаю, вам может быть лучше создать набор тестовых примеров CRED-операций с крайним случаем, которые реализуют сущности или операции на уровне данных. Если какой-либо из них не работает, база данных не синхронизируется с тем, что требуется. т.е. если вставка поля char (20) терпит неудачу, поскольку в базе данных это всего лишь char (15). Тогда сравнение структуры db можно сделать, чтобы увидеть, что делать, если выключено.

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

Ответ 6

Я тоже ищу ответ. Я думаю, что это должно быть протестировано в интеграционной среде, а не в unit test: для модульных тестов (DAL) я удаляю базу данных и воссоздаю ее.

Однако, в идеале, я хотел бы иметь интеграционную среду, так как моя БД реплицируется из производственного процесса, а сценарии миграции DB работают в обоих направлениях: Вверх, чтобы обеспечить плавное обновление продукции и вниз, чтобы обеспечить откаты.