Задачка на подумать...
Задачка на подумать...
Дано:
- производственный сервер, убивание которого крайне не желательно...
- вспомогательный сервер для тестирования - можно творить что угодно...
- бизнес-объекты (рукописные и генерируемые), функционирование которых нужно тестировать...
Ограничения:
- полную задачу вспомогательный сервер не тянет - нельзя перегнать полную базу и тестировать на вспомогательном сервере.
Требуется:
- протестировать функциональность бизнес-объектов.
Проблема: исходная база не содержит реляций между таблицами. Совсем. Есть индексы, но нет реляций.
Реляции задаются в достаточно неприятном СКЛ - только что убил полтора дня на заполнение данными вспомогательного сервера для тестирования ВСЕГО ДВУХ объектов.
Реляции - не полные. Есть много связок, которые, хотя и определяются как отношения в СКЛ-запросах, не могут быть реализованы как реляции в базе. Например, в связке используется только часть первичного ключа.
Вижу две задачи:
1. Получить сурогат реляций из запросов. Не(!) руками! И в виде, пригодном для определения в базе.
2. Организовать перегон данных с производственного сервера на вспомогательный (и/или в скрипты).
Во втором случае, меня интересует не полный перегон задействованных таблиц - это уже делается, а аккуратная фильтрация в соответствии с критериями в исходной задаче.
Т.е. если исходными данными является НомерЗаказа, то и данные нужны именно для данного заказа. При этом далеко не каждая из используемых таблиц будет непосредственно содержать НомерЗаказа, а кое-где НомерЗаказа будет давать ненужную избыточность - например, при 20 исправлениях заказа будет 19 избыточных версий.
Ну кроме этого еще желательно иметь три опции - с недостатком - когда копируются не все данные, с избытком - когда добавляются лишние, и точные - только нужные.
Как-то так.
Вопросы? Идеи?
П.С. Понимаю, что есть возможность часть работы переложить на МОСКи, но чтобы сгенерировать МОСКи надо решить указанные задачи.
А раздельные тесты на чтение и запись?
-----
Очень сильно не хочу.
Специально в архитектуре сделал так, чтобы поменять соединение с базой было не слишком просто.
Слишком велика цена ошибки - одно неправильное действие и завод встанет.
За три года такое случалось всего один раз - пересоздал ОДНУ таблицу. Все встало.
Пришлось звонить в сервис и восстанавливать из бекапа... за полчаса суппорт справился.
Но это - одна таблица в которой изменения были более чем редки.
Если запустить полный цикл тестов и ошибиться с соединением - будет больно - минимум суточная работа завода уйдет в потери. Выяснить и объяснить что именно потеряно - день-два простоя...
Так что Я постараюсь не коммутировать соединение при тестах.
Вот что подойдет - прочитать данные с производства и загнать их в скрипты - это нормально, это Я могу делать без напряга.
В другой части - использовать полученные скрипты для формирования данных и последующее тестирование.
Но! ПРОБЛЕМА!!! - В базе нет реляций.
Я не знаю какие именно данные мне надо вынимать чтобы протестировать объект с десятком задействованных в выборке таблиц.
Получить связи можно из того развесистого СКЛ который используется для заполнения объекта, но полученные связи не получается задать в модели.
Т.е. получается что для КАЖДОГО развесистого запроса надо делать кучу ручной работы. И повторять эту работу для получения каждого другого набора данных.
А именно этой ручной работы Я и хочу избежать.
Сейчас подумываю над следующим.
Создать тестовую базу. В принципе, что Оракле, что МС СКЛ, что Постргрее - почти без разницы. Для МС СКЛ инструментарий наиболее удобен.
Курочить модель в базе меняя ключи и индексы до получения модели-с-реляциями. Данная модель будет отличатся от оригинальной базы.
На базе модели-с-реляциями и информации об используемых параметрах - попытаться построить(сгенерировать) "извлекатель" данных и загонку данных в скрипты.
В принципе, не имею ничего против того, чтобы в скрипты была перегната ВСЯ имеющаяся база. 40-60 гиг скриптов, часов 30-40 на перегон.
И последнее - из имеющейся модели и сгенерированных скриптов построить(сгенерировать) загрузчик тестовых данных. Реально грузить 1-2% данных под тест.
Вроде должно получится.
Боюсь только что времени не хватит.