Создаём свои теги в RSpec тестах

Привет, меня зовут Леонид, и я работаю в команде, использующей Ruby on Rails, в компании Align Technology.
На работе мы используем рельсы в связке с RSpec, и сегодня я поделюсь нашим опытом о том, как облегчить себе жизнь при помощи собственных тегов в тестах.

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

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

Каждый тест для своего запуска получает собственный сгенерённый класс, в который, собственно, и подмешиваются DSL модули с нужными хелперами и ассертами.

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

Вот несколько полезных тегов, которые мы используем в нашей работе.

Контролируем работу поискового движка (на примере Sunspot)

Обычно поисковые библиотеки в рельсах интегрируются с ActiveRecord/ActiveModel классами, устанавливая туда after_save колбеки по вызову DSL метода конфигурации индексируемых полей.

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

Давайте добавим тег-правило, включающее отсылку данных в поисковый движок, только когда это необходимо.

spec/spec_helper.rb:

# --- :solr tag ---
# By default, Sunspot engine is disabled in any tests, with its connection stubbed.
# Add :solr tag to enable regular model indexing.
# Don't forget to run your search engine by corresponding rake task before running the suite.

config.before :suite do
  $real_solr_session = ::Sunspot.session
  ::Sunspot.session  = ::Sunspot::Rails::StubSessionProxy.new(::Sunspot.session)
end

config.before :each, solr: true do
  ::Sunspot.session  = $real_solr_session
end
config.after :each, solr: true do
  $real_solr_session = ::Sunspot.session
  ::Sunspot.session  = ::Sunspot::Rails::StubSessionProxy.new(::Sunspot.session)
end

Теперь просто пометьте ваши тесты, которым действительно нужен поисковый движок тегом :solr.
Например проверим, правильно ли работают синонимы в synonyms.txt:

spec/models/document.rb

it 'knows that tienda means store, in case someone will use \'STORE\' among spanish documents' do
  FactoryGirl.create :document, title: 'Lorem ipsum store dolor sit amet',
    searchable: true, locales: Locale.find_by(name:'es')
  Document.reindex

  Document.solr_search { fulltext 'tienda' }.hits.should have(1).document_match
  Document.solr_search { fulltext 'store' }.hits.should have(1).document_match
end

Тестируем миграции и "живые данные": база данных как fixture.

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

Это позволит делать ассёрты на настоящих данных, а также протестировать сложные миграции.

Итак, для тега :seeded тестов, которые начинают с "живого" БД-снапшота, нам понадобится несколько вещей. Первая — это Rake-таск, который достаёт свежий снапшот базы данных (например, снимаемый раз в сутки), и, если нужно, очищенный от важный продакшн-данных.

Второй момент такой: восстановление базы данных занимает время, поэтому давайте сначала запускать все "обычные" тесты, а потом сгруппируем тесты с "заполненной" базой, чтобы они запускались в самом конце:

spec/spec_helper.rb:

config.order_groups {|list| list.reject{|e| e.metadata[:seeded]}.shuffle(random: Random.new(config.seed)) \
                          + list.select{|e| e.metadata[:seeded]}.shuffle }

(Лучше при этом использовать обычный механизм запуска тестов в транзакции, которая в конце теста отменяется)

Заметим, что Rspec старается запускать тесты в случайном порядке, чтобы находить проблемы с состоянием, испорченным предыдущим тестом. (После этого отладка возможна с использованием того же порядка, если передать рспеку --seeded флаг с тем значением, которое он печатает при запуске) Поэтому мы следуем соглашению, и сбрасываем генератор случайных чисел на config.seed рспека.

Осталось задать самми правила для тега:

spec/spec_helper.rb:

# --- :seeded tag ---
# 1. have all :seeded tags grouped and executed at the end of the test suite
# 2. have your SQL test DB filled with fresh data from content master
# 3. then migrated from your migrations
# REQUIREMENTS:
#   A. all :seeded tests run one after another
#   B. :seeded tag is put on the top 'describe' blocks
config.before :all, seeded: true do
  unless $rspec_seeded_database
    Rails.application.load_tasks
    Rake::Task['db:restore_from_snapshot '].invoke
    Rake::Task['db:migrate'].invoke
    $rspec_seeded_database = true
    Rails.application.reload_routes!
    #Rake::Task['sunspot:reindex'].invoke
  end
end
config.after :all, seeded: true do end

Хорошо при этом в rake-таске db:restore_from_snapshot кешировать скачанный снапшот базы в папке tmp/, чтобы не загружать его каждый раз на машину разработчика.

Тестируем развернутое приложение

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

Пишем свой тег:

spec/spec_helper.rb:

    config.before :each, also_for_smoke_test: :true do
      Capybara.run_server        = false
      Capybara.app_host          = ENV['ACCEPTANCE_URL']
      Capybara.current_driver    = :webkit
    end

Теперь запускаем только нужную часть наших тестов как скрипт smoke-тестов:

ACCEPTANCE_URL=https://your-host.com rspec -t also_for_smoke_test

А какие теги-правила используете вы?