Стратегии тестирования драгоценных камней, чтобы убедиться, что драгоценные камни работают с Rails 3.x и 4.0?

Несколько вариантов из похожей темы на список основных рельсов:

Вариант 1: драгоценный камень оценки и единственное фиктивное приложение Rails

Кен Коллинз упомянул об использовании оценки и «фиктивного» приложения Rails:

Я тестирую minitest-spec-rails в сравнении с 3.0, 3.1, 3,2 и 4.0, используя сочетание оценки и dummy_app, которое минимально настраивается в зависимости от того, с какой версией рельсов оно тестируется. Некоторые ссылки:

https://github.com/metaskills/minitest-spec-rails https://github.com/metaskills/minitest-spec-rails/blob/master/test/dummy_app/init.rb

Подобные методы используются в less-rails, ember-rails и high_voltage среди прочих.

Я использовал настройку, аналогичную high_voltage в restful_json (v3.3.0), но с полным приложением Rails, созданным с помощью 4.0.0-beta1, которое я минимально модифицировал, чтобы оно также работало с Rails 3.1.x/3.2.x.

Обновление: может потребоваться просмотреть разрешения для более свежего примера.

Плюсы: Довольно просто. Можно тестировать различные версии Rails из командной строки и т. д. Может быть очень минимальная конфигурация приложения Rails или можно использовать полное приложение Rails с небольшими отличиями.

Минусы: по-прежнему повторно используется одно и то же приложение Rails для нескольких версий Rails, поэтому некоторые условные обозначения и ненужная конфигурация. (Возможны проблемы с некоторыми файлами, неприменимыми в другой версии Rails и т. д., но это не является большой проблемой.)

Вариант 2: версия Rails как переменная среды с одним Gemfile, одним фиктивным приложением Rails, полагаясь на travis-ci для тестирования в нескольких версиях.

Стив Клабник упомянул решение, которое работает с одним Gemfile, одним полным приложением Rails (хотя и в «пустом» каталоге и без использования оценочного драгоценного камня, полагаясь на travis-ci для тестирования:

Я собирался обсудить эту тему больше, так как в последнее время я делаю это для кучи моих драгоценных камней. У меня есть два, которые делают это:

Драйпер: https://github.com/drapergem/draper

LocaleSetter: https://github.com/jcasimir/locale_setter/

По сути, я встраиваю целое приложение Rails в гем, а затем запускаю его с несколькими версиями Rails на travis через env vars.

Плюсы: просто. Нет зависимости от драгоценного камня оценки (не то чтобы это было проблемой, но может быть проще в обслуживании).

Минусы: по-прежнему повторно используется одно и то же приложение Rails для нескольких версий Rails, насколько я могу судить. Если только не используется travis-ci или что-то, что начинается с чистого набора драгоценных камней (т. е. при работе в командной строке), в настоящее время не различаются наборы драгоценных камней, поэтому более новый драгоценный камень может использоваться со старыми Rails и т. д., но Стив сказал, что если это вызовет проблему , можно было просто сдуть блокировку и заново связать.

Есть и третий вариант: использование нескольких гемфайлов и нескольких фиктивных приложений.

Gemfiles

В Bundler есть полезная опция --gemfile. С его помощью вы можете указать, какой файл использовать вместо Gemfile, и он сгенерирует файл блокировки после того же имени:

bundle install --gemfile Gemfile.rails3
bundle install --gemfile Gemfile.rails4

Это создаст Gemfile.rails3.lock и Gemfile.rails4.lock. Итак, эти Gemfiles могут быть копией вашего основного Gemfile, форсирующего версию rails:

source "http://rubygems.org"
gemspec
gem "jquery-rails"
gem "rails", '~>4' 

Использование gem-файлов из фиктивных приложений

Тогда у вас есть два фиктивных приложения, одно для rails-3 и одно для rails-4. Чтобы использовать их правильный gemfile при выполнении (например) миграции:

cd test/dummy_rails3
BUNDLE_GEMFILE=../../Gemfile.rails3 bundle exec rake db:migrate
cd ../dummy_rails4
BUNDLE_GEMFILE=../../Gemfile.rails4 bundle exec rake db:migrate

Да, это, пожалуй, худшая часть. Но это в основном разовая установка.

Использование гемфайлов из рейка

Чтобы указать, какую версию использовать при выполнении тестов, установите переменную среды BUNDLE_GEMFILE в Rakefile:

#!/usr/bin/env rake

rails_version = ENV[ 'RAILS_VERSION' ] || '4'

if rails_version == '3'
  ENV[ 'BUNDLE_GEMFILE' ] = 'Gemfile.rails3'
else
  ENV[ 'BUNDLE_GEMFILE' ] = 'Gemfile.rails4'
end

begin
  require 'bundler/setup'
rescue LoadError
  puts 'You must `gem install bundler` and `bundle install` to run rake tasks'
end

Я предпочитаю просить пользователя передать RAILS_VERSION вместо прямого BUNDLE_GEMFILE, потому что его легче запомнить, и мы можем просто передать «3» или «4».

Использование правильного фиктивного приложения из тестов

Наконец, в test_helper переключите фиктивное приложение в зависимости от запрашиваемой версии rails:

# Configure Rails Environment
ENV["RAILS_ENV"] = "test"

dummy_app = ENV[ 'RAILS_VERSION' ] == '3' ? 'dummy_rails3' : 'dummy_rails4'

require File.expand_path("../#{dummy_app}/config/environment.rb",  __FILE__)
require "rails/test_help"

С вашей точки зрения пользователя

Чтобы ваш пользователь мог запускать тесты, ему нужно будет выполнить однократную настройку, запустив задачи миграции с BUNDLE_GEMFILE, что не так уж и привлекательно.

Но после этого пользователь может запускать тесты для rails-3 и rails-4 без необходимости генерировать Gemfile каждый раз, когда он хочет сменить версию, и вы можете иметь код и конфигурацию для конкретной версии в своих тестовых приложениях без необходимости помещать операторы if Rails.version >= '4' где угодно.

Чтобы запустить спецификации:

RAILS_VERSION=3 bundle exec rake test
bundle exec rake test # rails-4 is the default in code I wrote

Вы можете увидеть пример этого метода в моем геме activerecord_any_of.