Актуализация начальной базы

Прошел год с момента создания новой тестовой базы. База создавалась из начальной базы. Подход был описан в заметке Тестирование базы данных и тестовые данные. Использовался вариант 4 Создавать уникальные данные при каждом запуске.

За время использования база выросла и заматерела. Из-за количества записей увеличилось время поиска элементов в списках при подборе значений, тем самым еще больше увеличивая общее время выполнения тестов. Пришло время "обновить" тестовую базу, заменив ее начальной.

Открываем начальную базу и узнаем, в она в том состоянии что была год назад. За год появилось множество нового функционала и различных настроек. Начальная база требует актуализации.

Очевидные шаги по подготовке новой тестовой базы: берем начальную базу, обновляем в ней конфигурацию и добавляем недостающие настройки. Сложность в том, что настройки размазаны тонким слоем по данным конфигурации. В заметке Варианты тестового окружения были рассмотрены виды настроек и тестового окружения: Настройки-базы, Настройки-аналитик, Глобальное окружение.

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

Самое очевидное решение: взять настройки тестовой базы и перенести их в начальную базу. Полностью автоматизировать синхронизацию невозможно, т.к. в тестовой базе нет признака, что конкретный набор данных относится к настройкам. Такая надстройка над настройками не только усложнит архитектуру, но в свою очередь потребует ручную поддержку и актуализацию.

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

Далее актуальную начальную базу загружаем в тестовую базу.

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

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