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

Question

Я работаю над проектом, в котором мы преобразуем старую систему в совершенно новую. В настоящее время мы преобразованы из базы данных старой системы в базу данных новой системы, и команда работает над созданием набора карт и преобразований для запуска в конце разработки для преобразования поверх старой системы.

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

Есть предложения или идеи, как это сделать? Я не думаю, что есть рамки для этого, но если есть, я хотел бы знать об этом.

(Обновлено)

Это база данных Oracle, которая, вероятно, является полезной информацией.

Answer 1

Первое, что вам нужно сделать в этой ситуации, это решить, какой у вас «Юнит». А затем выясните, какой должна быть его функциональность. После этого вы можете проверить это, как и все остальное.

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

Answer 2

Это специфично для Oracle, но если это ваша база данных, вам следует попробовать Ounit .

Answer 3

Это на самом деле не подходит для модульного тестирования.

«Новая» база данных обычно логически несовместима, пока все преобразования не будут завершены. Кроме того, большинство ошибок будет связано с несоответствиями в отображениях и способах их обработки нулевыми внешними ключами и т. Д.

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

Answer 4

Я делал подобные вещи в прошлом; Я не понимаю, как тестирование всей вашей миграции может быть «модульным тестом». Может быть, вы можете рассмотреть "Общая сумма всех продаж в новой базе данных должна быть старой базы данных". Модульные тесты на самом деле не нужны, если только вы не пишете отдельные функции PL / SQL, чтобы помочь с преобразованием (то есть преобразование из одного способа хранения столбца в другой). Это должно быть тривиально для модульного теста.

Некоторые из тестов, которые я делал в прошлом: -

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

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

Answer 5

Вы можете попробовать dbUnit или SqlUnit . Эта статья , относящаяся к MS, может быть полезна для понимания некоторых шаблонов тестирования БД.

Предостережение: я не использовал ни одного из них и поэтому не могу давать никаких рекомендаций.