Simple answer: use factory.sequence If you have a field that needs to be unique you can add a sequence in factory_girl to ensure that it is never the same: Factory.define :user do |user| sequence(:email){|n| “user#{n}@factory.com” } user.password{ “secret” } end This will increment n each time in order to produce a unique email address such … Read more
You need to pass a block if you want the values re-evaluated for each instance created. Instead of email Faker::Internet.email try… email { Faker::Internet.email }
Machinist was actually heavily inspired by factory_girl, but varied because machinist’s author wanted a different syntax. Since then, factory_girl added different syntax layers to simulate other factory libraries (including machinist’s “blueprint” syntax). In other words, both are extremely similar, just with a different default syntax. Personally, I use factory_girl.
You commented on my similar question a bit ago, and I found an answer that might help you as well. Upgrading to Devise 3.1.0 left some ‘cruft’ in a view that I hadn’t touched in a while. According to this blog post, you need to change your Devise mailer to use @token instead of the … Read more
It should be FactoryGirl.create instead. Apparently Factory was deprecated and now has been removed, look at the comments in the link you provided 🙂
Callback and Callback behavior are independent tests. If you want to check an after_save callback, you need to think of it as two things: Is the callback being fired for the right events? Is the called function doing the right thing? Assume you have the Article class with many callbacks, this is how you would … Read more
TL;DR FactoryGirl tries to be helpful by making a very large assumption when it creates it’s “stub” objects. Namely, that: you have an id, which means you are not a new record, and thus are already persisted! Unfortunately, ActiveRecord uses this to decide if it should keep persistence up to date. So the stubbed model … Read more
The Factory.after_ hooks appear to be the only way to do this successfully. I’ve figured out a way to maintain the build strategy without duplicating code: Factory.define :foo do |f| f.name “A Foo” f.after(:build) { |foo| foo.bars << Factory.build(:bar, :foo => foo) } f.after(:create) { |foo| foo.bars.each { |bar| bar.save! } } end The documentation … Read more
attributes_for will return a hash, whereas build will return a non persisted object. Given the following factory: FactoryGirl.define do factory :user do name ‘John Doe’ end end Here is the result of build: FactoryGirl.build :user => #<User id: nil, name: “John Doe”, created_at: nil, updated_at: nil> and the result of attributes_for FactoryGirl.attributes_for :user => {:name=>”John … Read more
Just FYI, you can also use the initialize_with macro inside your factory and check to see if the object already exists, then don’t create it over again. The solution using a lambda (its awesome, but!) is replicating logic already present in find_or_create_by. This also works for associations where the :league is being created through an … Read more