Предпочитаемый плагин замены светильников в Rails?

Ответ 1

Я лично использую Faker с пользовательским классом Factory. Это позволяет мне создавать мои фабрики и заполнять сгенерированные экземпляры нестатистическими данными.

# spec/factory.rb
module Factory
  def self.create_offer(options={})
    Offer.create({
      :code => Faker::Lorem.words(1),
      :expires_on => Time.now + (rand(30) + 1).day
    }.merge(options))
  end
end


# spec_helper.rb
require 'faker'
require 'spec/factory'


# In the specs
@offer = Factory.create_offer(:code => 'TESTING')

Ответ 2

Я буду защищать Замена светильников 2. Ваши атрибуты модели по умолчанию (не заботятся) сохраняются в одном месте, db/example_data.rb и обеспечивают быстродействующие объекты. Любые атрибуты, которые вы указываете при создании, переопределяют атрибуты по умолчанию - это означает, что данные находятся в в тесте, и ничего больше.

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

Версия 2 обеспечивает гораздо более чистый формат определения, но при этом все еще предоставляет магические методы new_*, create_*, and default_* для каждой модели.

Я бы избегал любой схемы "сценариев", которая поощряет создание все большего числа тестовых данных, которые трудно читать позже. Вы можете создавать именованные (пользовательские) объекты с помощью FR2, но я никогда не нашел в этом необходимости.

P.S. Удостоверьтесь, что вы считаете стратегию тестирования единиц, а также - светильники и все их аналоги являются реальными объектами, которые попадают в БД, что делает для функциональных или интеграционных тестов. В настоящее время я использую RSpec, расстроенный вместе с stub_model() и последним unit_record, чтобы запретить доступ к БД.

Ответ 3

Я могу дать Factory Девушка плюс плюс. Способ, которым он может связываться между несколькими Фабриками, действительно полезен, когда у вас есть несколько нормальный набор моделей. Например, у проекта есть один менеджер проектов.

Factory.define :project_manager do |f|
  f.first_name "John"
  f.last_name  "Doe"
end

Factory.define :project do |f|
  f.name "Sample Project"
  f.association :project_manager
end

Таким образом, вам не нужно беспокоиться о фактической настройке отношений в каждом тесте. Он также может выполнять некоторую работу, например, Faker, где вы можете создавать образцы данных на фабриках, используя Factory.sequence. Для всей информации о Factory Girl, проверьте: http://dev.thoughtbot.com/factory_girl/.

Ответ 4

+1 factory девушка

Ответ 5

Мы только начали использовать Factory Girl для наших проектов. Его способ делать вещи не сильно отличался от нашего домашнего решения, поэтому он хорошо работает для нас.

Ответ 6

Я использую Faker вместе с камнем Populator Райаном Бейтсом. У него даже есть хороший скринкаст в http://railscasts.com/episodes/126-populating-a-database.

Ответ 7

Я большой поклонник factory, когда вам нужен только один или несколько объектов. Вы можете либо написать свой собственный, либо использовать Thoughtbot Factory Девушка.

В ситуациях, когда вам нужен кураторский набор взаимосвязанных объектов, fixtures beat factory, и вы должны взглянуть на отличный Lite Fixtures, что делает крепления значительно более сухими и управляемыми.

Ответ 8

Я играл с machinist в последнее время и копаю его.

Ответ 9

Factory Девушка замечательная. Мы используем его в рабочих нагрузках.

Factory.define :usa, :class => Team do |f|
  f.country_name 'USA'
  f.rank         15.6
end

Factory.define :player do |f|
  f.first_name 'Stevie'
  f.last_name  'Wonder'
  f.team       Factory.build(:usa)
end

Затем в ваших спецификациях вы можете использовать Factory.build(:usa) или Factory.create(:usa) для создания или создания команды США соответственно.