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

Question

Я использую Migrator.NET для записи миграций базы данных для приложения. Марк-Андре Курнойер писал:

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

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

EDIT Я имею в виду миграцию в смысле Rails ActiveRecord Migrations (создание, изменение и разрушение баз данных небольшими шагами на основе кода C #).

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

Может быть, этот скрипт может помочь вам:

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

этот скрипт сравнивает две базы данных (структура и данные)

Answer 5

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

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

Answer 6

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

Я думаю, что вам может быть лучше создать набор контрольных примеров операций CRUD с пограничным регистром, которые осуществляют сущности или операции на уровне данных. В случае сбоя любого из них база данных не синхронизируется с тем, что требуется. то есть, если вставка поля char (20) завершится неудачно, потому что в базе данных есть только char (15). Затем можно сделать сравнение структуры БД, чтобы увидеть, что если выключено.

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