Справочная информация: у нас есть зависимость от базы данных с внешним управлением. Это общеорганизационный ресурс. У нас есть учетная запись только для чтения, и мы не можем контролировать или вводить данные в схему или содержимое.
Проблема: мы используем ActiveRecord в качестве ORM для указанного ресурса; мы управляем информацией о соединении отдельно от нашей центральной информации о соединении БД. Это сработало нормально. У нас есть некоторые тесты характеристик, которые подтверждают, что наши ActiveRecords извлекают данные для нескольких известных точек данных. Однако у нас нет стратегии замены среды тестирования / разработки для этой базы данных. Сейчас все наши среды настроены на использование соединения с производственной базой данных:
- Это отстой
- Нам не нужен рабочий пароль на сервере сборки, поэтому наша сборка не работает
- Запросы к производственному серверу баз данных медленные, и поскольку кэширование отключено в test / dev, наша домашняя страница загружается очень медленно локально
Так что нам нужно что-то еще в режиме тестирования / разработки.
В) Почему бы просто не иметь локальную базу данных sqlite, которая имитирует схему производственной базы данных?
А) Потому что мы пробовали это для другого соединения, и это паршиво, по крайней мере, по нескольким причинам.
- Довольно сложно управлять отдельной схемой (файлом sqlite db) в процессе rake только для тестирования / dev.
- Тестирование ActiveRecords вне схемы, управляемой каким-либо процессом, который обеспечивает согласованность схемы между средами, в значительной степени бессмысленно.
- Конфигурация базы данных не выглядит как правильный шов. Этот аспект соединения с базой данных, и, следовательно, AR, не является частью того, что мы разрабатываем, в данном случае это просто библиотека соединений. Пока мы можем гарантировать, что наша замена test / dev для него действует так же, как и производственная AR, не имеет значения, используем ли мы AR для этого в test / dev. Надеюсь, это имело смысл, это важный момент.
В) Вы можете использовать SchemaDumper, чтобы получить схему производственной базы данных и использовать ее для создания тестовой базы данных. Таким образом, все детали SQLy будут автоматизированы, и это будет больше похоже на типичные рельсы.
A) Да, это было бы довольно жарко, но SchemaDumper, похоже, не очень хорошо работает с подключением к производственной базе данных. Это просто зависает через некоторое время, и мы не получаем всю схему. Облом. Это также не избавляет от необходимости управлять всем этим другим файлом базы данных и работать с этим файлом в наших задачах rake.
То, что я действительно хочу сделать, - это использовать в производственном процессе AR, которые были протестированы в тестах характеристик, а затем иметь другой объект, который представляет собой обычный старый PORO, который считывает данные из файла yaml (например, приборы), который заменяет объект в средах тестирования / разработки / сборки.
В) Но Наджати, не помещает ли этот материал в файл yaml то же самое, что и определение схемы?
А) Ну, да, Сорта. Его намного проще и проще управлять, если он находится в некотором PORO, который загружает какую-то ерунду из файла yamlfile, чем если бы мне также приходилось работать с каким-то недоделанным управлением схемами в наших задачах сборки; мы делаем это в настоящее время, и это довольно отвратительно и, честно говоря, похоже, не очень-то нас покупает. Кроме того, схема теста и тестовая база данных дублируют информацию: «это то, что мы хотим, чтобы тестовая версия этих данных была похожа» - зачем нам оба? Я заявляю: «Чтобы вы могли использовать один и тот же AR в обеих средах». не является достаточным аргументом для обоснования сложности управления дополнительным файлом sqlite db.
В) Я чувствую, что ты что-то мне не говоришь.
A) Я изменял своим наблюдателям за весом. Кроме того,
В прошлом, когда у меня было что-то подобное, мое решение выглядело так:
- Тесты характеристик, которые фиксируют важные аспекты поведения внешней службы, выполняются не с набором модульных тестов, а как отдельный процесс на сервере сборки, возможно один раз каждые 4 часа или каждую ночь или как угодно.
- Фальшивая реализация, которая использовала тот же набор тестов для проверки своего поведения, чтобы гарантировать, что она обеспечивает аналогичную функциональность для среды test / dev.
Spring (и, вероятно, контейнеры для инъекций зависимостей в целом) делаетэто легко.Вы просто заменяете bean-компоненты в своей конфигурации bean-компонентов, специфичных для среды, и тестовая среда просто идет своим чередом.
Учитывая мое понимание / знания, Rails, похоже, не очень хорошо поддается этому.Я предполагал, что смогу переопределить класс в моих сценариях среды тестирования / разработки, но это кажется очень сомнительным.Во-первых, я не знаю, будет ли это препятствовать загрузке модели при запуске приложения, и, с другой стороны, это добавит еще одну странную складку в наш проект Rails, еще одну магию, которая сделает проект труднеенабирай скорость.Я хочу что-то похожее на стратегию «замены сервисов», используемое в Spring, которое не требует трудно найти / понять магию RoR.
Э-э-э.Я остановлюсь там и посмотрю, что это подсказывает.Спасибо, что нашли время, чтобы прочитать!