Фикстуры — способ организации данных, используемых для тестирования; короче говоря, образцовые данные.

Они хранятся в файлах YAML, по одному файлу на модель, которые размещаются в директории, указанной в ActiveSupport::TestCase.fixture_path=(path) (это автоматически настраивается для Rails, поэтому вы можете просто положить свои файлы в <your-rails-app>/test/fixtures/). Файл фикстуры заканчивается расширением .yml, например: <your-rails-app>/test/fixtures/web_sites.yml).

Формат файла фикстуры выглядит следующим образом:

rubyonrails:
  id: 1
  name: Ruby on Rails
  url: http://www.rubyonrails.org

google:
  id: 2
  name: Google
  url: http://www.google.com

Этот файл фикстур содержит две фикстуры. Каждая фикстура YAML (т. е. запись) получает имя и сопровождается отступающим списком пар ключ-значение в формате «ключ: значение». Записи разделены пустой строкой для удобства просмотра.

Примечание: Фикстуры не упорядочены. Если вам нужны упорядоченные фикстуры, используйте тип YAML omap. См. yaml.org/type/omap.html для спецификации. Вам понадобятся упорядоченные фикстуры, когда у вас есть ограничения на внешние ключи по ключам в одной таблице. Это обычно требуется для древовидных структур. Пример:

--- !omap
- parent:
    id:         1
    parent_id:  NULL
    title:      Parent
- child:
    id:         2
    parent_id:  1
    title:      Child

Использование фикстур в тестовых случаях

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

require 'test_helper'

class WebSiteTest < ActiveSupport::TestCase
  test "web_site_count" do
    assert_equal 2, WebSite.count
  end
end

По умолчанию, test_helper.rb загрузит все ваши фикстуры в вашу тестовую базу данных, поэтому этот тест пройдет.

Тестовая среда автоматически загрузит все фикстуры в базу данных перед каждым тестом. Для обеспечения согласованности данных среда удаляет фикстуры перед запуском загрузки.

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

test "find" do
  assert_equal "Ruby on Rails", web_sites(:rubyonrails).name
end

В качестве альтернативы, вы можете включить автоматическое создание экземпляров данных фикстуры. Например, рассмотрим следующие тесты:

test "find_alt_method_1" do
  assert_equal "Ruby on Rails", @web_sites['rubyonrails']['name']
end

test "find_alt_method_2" do
  assert_equal "Ruby on Rails", @rubyonrails.name
end

Для использования этих методов для доступа к данным фикстуры в ваших тестовых случаях, вы должны указать одно из следующего в вашем классе, производном от ActiveSupport::TestCase:

• для полного включения созданных экземпляров фикстур (включите альтернативные методы №1 и №2 выше)

  self.use_instantiated_fixtures = true
  

• создать только хеш для фикстур, не «находить» каждый экземпляр (включите только альтернативный метод №1)

  self.use_instantiated_fixtures = :no_instances
  

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

Динамические фикстуры с

Иногда вас не так интересует содержание фикстур, как их объем. В таких случаях вы можете смешать ERB с файлами фикстур YAML для создания множества фикстур для тестирования нагрузок, например:

<% 1.upto(1000) do |i| %>
fix_<%= i %>:
  id: <%= i %>
  name: guy_<%= i %>
<% end %>

Это создаст 1000 очень простых фикстур.

Используя ERB, вы также можете вводить динамические значения в свои фикстуры с вставками, такими как <%= Date.today.strftime("%Y-%m-%d") %>. Однако это функция, которую следует использовать с осторожностью. Суть фикстур — в том, что они представляют собой стабильные единицы предсказуемых образцовых данных. Если вам нужно вводить динамические значения, возможно, вам следует пересмотреть, правильно ли ваш инструмент подходит для тестирования приложения. Таким образом, динамические значения в фикстурах следует рассматривать как признак плохой практики кодирования.

Вспомогательные методы, определенные в фикстуре, не будут доступны в других фикстурах, чтобы предотвратить нежелательные зависимости между тестами. Методы, используемые несколькими фикстурами, должны быть определены в модуле, который включён в ::context_class.

• определить вспомогательный метод в `test_helper.rb`

  module FixtureFileHelpers
    def file_sha(path)
      Digest::SHA2.hexdigest(File.read(Rails.root.join('test/fixtures', path)))
    end
  end
  ActiveRecord::FixtureSet.context_class.include FixtureFileHelpers
  

• использовать вспомогательный метод в фикстуре

  photo:
    name: kitten.png
    sha: <%= file_sha 'files/kitten.png' %>

Транзакционные тесты

Тестовые случаи могут использовать begin+rollback, чтобы изолировать свои изменения в базе данных вместо того, чтобы каждый раз удалять и вставлять данные для каждого тестового случая.

class FooTest < ActiveSupport::TestCase
  self.use_transactional_tests = true

  test "godzilla" do
    assert !Foo.all.empty?
    Foo.destroy_all
    assert Foo.all.empty?
  end

  test "godzilla aftermath" do
    assert !Foo.all.empty?
  end
end

Если вы предварительно загружаете свою тестовую базу данными всех данных фикстур (вероятно, в задаче rake) и используете транзакционные тесты, то вы можете опустить все объявления фикстур в своих тестовых случаях, поскольку все данные уже там, и каждый случай откатывает свои изменения.

Для использования созданных экземпляров фикстур с предварительно загруженными данными установите self.pre_loaded_fixtures в значение true. Это обеспечит доступ к данным фикстуры для каждой таблицы, которая была загружена с помощью фикстур (в зависимости от значения use_instantiated_fixtures).

Когда не следует использовать транзакционные тесты:

1. Вы тестируете, работает ли транзакция правильно. Вложенные транзакции не выполняют коммиты, пока не выполнят коммит все родительские транзакции, в частности, транзакция фикстур, которая начинается в настройке и откатывается в завершении. Таким образом, вы не сможете проверить результаты вашей транзакции, пока Active Record не поддерживает вложенные транзакции или точки сохранения (на стадии разработки).

2. Ваша база данных не поддерживает транзакции. Каждая база данных Active Record поддерживает транзакции, за исключением MySQL MyISAM. Используйте InnoDB, MaxDB или NDB вместо неё.

Расширенные фикстуры

Фикстуры, которые не указывают ID, получают дополнительные функции:

• Стабильные автоматически сгенерированные ID

• Ссылки на метки для ассоциаций (belongs_to, has_one, has_many)

• HABTM ассоциации как списки в строке

Есть ещё некоторые расширенные возможности, доступные даже если ID указан:

• Автозаполнение столбцов временных меток

• Интерполяция меток фикстуры

• Поддержка значений по умолчанию YAML

Стабильные, автоматически сгенерированные ID

Вот пример фикстуры обезьяны:

george:
  id: 1
  name: George the Monkey

reginald:
  id: 2
  name: Reginald the Pirate

Каждая из этих фикстур имеет два уникальных идентификатора: один для базы данных и один для людей. Почему бы нам не сгенерировать первичный ключ? Хеширование каждой метки фикстуры дает постоянный ID:

george: # generated id: 503576764
  name: George the Monkey

reginald: # generated id: 324201669
  name: Reginald the Pirate

Active Record обращается к классу модели фикстуры, определяет правильный первичный ключ и генерирует его непосредственно перед вставкой фикстуры в базу данных.

Сгенерированный ID для заданной метки остается постоянным, поэтому мы можем определить ID любой фикстуры без загрузки чего-либо, если нам известна её метка.

Ссылки на метки для ассоциаций (belongs_to, has_one, has_many)

Указание внешних ключей в фикстурах может быть очень неустойчивым, не говоря уже о сложности чтения. Поскольку Active Record может определить ID любой фикстуры по её метке, вы можете указывать FK по метке вместо ID.

belongs_to

Давайте рассмотрим ещё обезьян и пиратов.

### in pirates.yml

reginald:
  id: 1
  name: Reginald the Pirate
  monkey_id: 1

### in monkeys.yml

george:
  id: 1
  name: George the Monkey
  pirate_id: 1

Добавьте ещё несколько обезьян и пиратов, разбейте это на несколько файлов, и станет довольно сложно отслеживать происходящее. Давайте используем метки вместо ID:

### in pirates.yml

reginald:
  name: Reginald the Pirate
  monkey: george

### in monkeys.yml

george:
  name: George the Monkey
  pirate: reginald

Всё стало ясно. Active Record анализирует класс модели фикстуры, находит все belongs_to ассоциации и позволяет указать целевую метку для ассоциации (обезьяна: джордж) вместо целевого ID для FK (monkey_id: 1).

Полиморфные belongs_to

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

### in fruit.rb

belongs_to :eater, polymorphic: true

### in fruits.yml

apple:
  id: 1
  name: apple
  eater_id: 1
  eater_type: Monkey

Можно ли сделать лучше? Конечно!

apple:
  eater: george (Monkey)

Просто укажите полиморфный целевой тип, и Active Record позаботится об остальном.

has_and_belongs_to_many

Время дать нашей обезьяне немного фруктов.

### in monkeys.yml

george:
  id: 1
  name: George the Monkey

### in fruits.yml

apple:
  id: 1
  name: apple

orange:
  id: 2
  name: orange

grape:
  id: 3
  name: grape

### in fruits_monkeys.yml

apple_george:
  fruit_id: 1
  monkey_id: 1

orange_george:
  fruit_id: 2
  monkey_id: 1

grape_george:
  fruit_id: 3
  monkey_id: 1

Давайте уберем фикстуру HABTM.

### in monkeys.yml

george:
  id: 1
  name: George the Monkey
  fruits: apple, orange, grape

### in fruits.yml

apple:
  name: apple

orange:
  name: orange

grape:
  name: grape

Всё готово! Больше нет файла fruits_monkeys.yml. Мы указали список фруктов в фикстуре Джорджа, но мы могли бы так же легко указать список обезьян для каждого фрукта. Как и в случае с belongs_to, Active Record анализирует класс модели фикстуры и определяет has_and_belongs_to_many ассоциации.

Автозаполнение столбцов временных меток

Если ваша таблица/модель определяет какие-либо стандартные столбцы временных меток Active Record (created_at, created_on, updated_at, updated_on), они будут автоматически установлены на Time.now.

Если вы установили определённые значения, они останутся без изменений.

Интерполяция метки фикстуры

Метка текущей фикстуры всегда доступна как значение столбца:

geeksomnia:
  name: Geeksomnia's Account
  subdomain: $LABEL
  email: $LABEL@email.com

Также, иногда (например, при переносе старых фикстур таблиц объединения) вам нужно будет получить идентификатор для заданной метки. ERB на выручку:

george_reginald:
  monkey_id: <%= ActiveRecord::FixtureSet.identify(:reginald) %>
  pirate_id: <%= ActiveRecord::FixtureSet.identify(:george) %>

Поддержка значений по умолчанию YAML

Вы можете задать и повторно использовать значения по умолчанию в файле фикстур YAML. Это тот же метод, который используется в файле database.yml для задания значений по умолчанию:

DEFAULTS: &DEFAULTS
  created_on: <%= 3.weeks.ago.to_s(:db) %>

first:
  name: Smurf
  <<: *DEFAULTS

second:
  name: Fraggle
  <<: *DEFAULTS

Любая фикстура с меткой «DEFAULTS» безопасно игнорируется.

Настройка класса модели фикстуры

Можно напрямую задать класс модели фикстуры в файле YAML. Это полезно, когда фикстуры загружаются вне тестов и set_fixture_class недоступен (например, при запуске rails db:fixtures:load).

_fixture:
  model_class: User
david:
  name: David

Любые фикстуры с меткой «_fixture» безопасно игнорируются.