Как я тестирую миграции базы данных?
Я использую Migrator.NET для записи миграций базы данных для приложения. Marc-André Cournoyer записал:
Как любой код в Вашем приложении необходимо протестировать миграции. Код взлетов и падений. Сделайте это часть Вашего непрерывного процесса сборки и протестируйте его на стольких различных базах данных и среде, сколько Вы можете.
Как я делаю это? Скажите, что я имею () метод, который составляет таблицу и Вниз () метод, который отбрасывает ту же таблицу, и я использую SQL Server. Как тест был бы похож? Если я выполняю SQL-запрос против системных таблиц, как select * from sys.columns, проверять, была ли таблица составлена и что она имеет надлежащую структуру? Что, если мы используем NHibernate?
ОТРЕДАКТИРУЙТЕ я имею в виду миграции в направляющих смысл Миграций ActiveRecord (создание, изменение и базы данных разъединения в небольших шагах на основе кода C#).
ОТРЕДАКТИРУЙТЕ 2, И вот то, где я читал, о котором мы должны протестировать миграции. Сообщение в блоге на самом деле связано от Wiki Мигранта.
6 ответов
Вы тестируете свой DAL - своего рода интеграционный тест?
Вам нужно больше, чем сценарий миграции, вам также нужен базовый сценарий. Если вы хотите протестировать обновление базы данных, вам следует запустить все сценарии из базового уровня на тестовом / промежуточном сервере, чтобы создать новейшую версию базы данных. Затем проверьте свой DAL в актуальной тестовой базе данных. Если все тесты DAL пройдены успешно, значит, ваша миграция должна быть успешной (в противном случае ваши тесты DAL будут недостаточно полными).
Это дорогостоящий тест, но он в значительной степени надежен. Я лично признаю, что в настоящий момент много делаю это вручную; у нас есть собственный инструмент миграции, который применяет все сценарии (включая базовый уровень), поэтому настройка тестовой базы данных и тесты DAL - это отдельные шаги. Хотя это работает. Если вы хотите убедиться, что таблица была создана, нет лучшего способа, чем попытаться вставить в нее данные!
Вы можете попробовать проверить результаты, просмотрев системные каталоги и INFORMATION_SCHEMA представления и так далее, но в конечном итоге единственный способ убедиться, что он действительно работает , - это попытаться используйте новые объекты. Просто потому, что объекты есть, не означает, что они функциональны.
возможно, этот скрипт может вам помочь:
http://www.benzzon.se/forum/uploads/benzzon/2006-03-27_134824_sp_CompareDB.txt
этот скрипт сравнивает две БД (структуру и данные)
Контроль исходного кода - это для создания снимка текущей кодовой базы. Миграция - это перенос изменений вашей базы данных из одной версии в другую. Чтобы в какой-то момент в будущем вы могли взять старую базу данных, применить миграции и работать с последней кодовой базой.
Я никогда не видел, чтобы миграции тестировались. Я видел результаты тестирования, и они поймали/напомнили мне о необходимости запуска последних миграций.
describe User do
it { should have_column :name, :type => :string }
it { should validate_presence_of :name}
end
Итак, кто-то меняет модель. Добавляет тест, отражающий модель. Добавляет миграцию. Затем коммитит исходный текст.
Вы берете последнюю версию, запускаете тесты. Тесты не работают, потому что база данных не соответствует. Вы вспоминаете, что нужно запустить миграции, затем повторно запускаете тесты. Успех.
Вы МОЖЕТЕ провести сравнение системных объектов базы данных, но вам понадобится цель для сравнения - иначе как вы узнаете, пройдено или нет ?
Думаю, вам может быть лучше создать набор тестовых примеров операций CRUD пограничного случая, которые проверяют сущности или операции на уровне данных. Если какой-либо из них не работает, база данных не синхронизирована с тем, что требуется. то есть, если вставка поля char (20) не удалась, потому что в базе данных есть только char (15). Затем можно провести сравнение структуры базы данных, чтобы увидеть, что если отключено.
Вы можете устранить это, сосредоточив внимание только на недавно измененных элементах и предполагая, что были применены предыдущие изменения.
Рассматривайте тестирование миграций как часть общей стратегии тестирования устойчивости при использовании NHibernate, т. Е. Если вы можете создавать и сохранять все свои объекты без каких-либо ошибок, ваша база данных и ваши сопоставления должны быть правильными.
Я тоже ищу ответ. Я думаю, что это следует тестировать в среде интеграции, а не в среде модульного тестирования: для модульных тестов (DAL) я отбрасываю базу данных и создаю ее заново.
Однако в идеале я бы хотел иметь среду интеграции, в которой моя БД реплицируется из производственной среды, а сценарии миграции БД выполняются в обоих направлениях: вверх, чтобы обеспечить плавное обновление производственной среды, и вниз, чтобы гарантировать возможность отката. .