Foolproof FactoryGirl Sequence

Turns out Sequencing in FactoryGirl isn't as easy as it used to be.
Factory.next has been deprecated and the two obvious ways to make a sequence now throw Trait error or Attribute already defined error "FactoryGirl::AttributeDefinitionError"

The problem with this first approach is name. In a normal sequence you would just say name but I want to use it in the description too. This somehow makes FactoryGirl believe name is a trait.

FactoryGirl.define do
  
  sequence(:code) {|n| "#{n+1000}"}
  
  factory :course do |u|
    name "CS#{ generate :code }"
    description "#{name}, 1st year, 1st semester, Foundation Of #{name}"
  end
end

This next example has a problem with the description line. This causes the description to generate 2 more names and throw an AttributeDefinitionError because you now have more than 1 name generated.
For some reason you cannot get around it by making the name line name = Factory.generate :name because name becomes a Trait again.

FactoryGirl.define do
  
  sequence(:name) {|n| "CS#{n+1000}"}
  
  factory :course do |u|
    name
    description "#{name}, 1st year, 1st semester, Foundation Of #{name}"
  end
end

This is the only thing that works. Static forcing FactoryGirl to use the already defined name again using the |a| block in description. It isn't as pretty as it could be but I have to live with it unless someone can tell me a better way. There is probably a solution where you use an after_build tag but that makes it longer and more complicated unnecessarily and it would still be ugly.

FactoryGirl.define do
  
  sequence(:name) {|n| "CS#{n+1000}"}
  
  factory :course do |u|
    u.name
    u.description {|a| "#{a.name}, 1st year, 1st semester, Foundation Of #{a.name}"}
  end
end

Seeding the Test Database

Edit: this post was edited with new information as it was found. As such it is a mess. There are two solutions to loading the same seed data in test as the other environments: Loading your seeds.rb from factories in the spec, or loading your seeds into the testing environment. I prefer the first option as you get to make your seeds with FactoryGirl and it gets validated and if you are loading your seeds in spec, you need to call the method to load it before(:all) every time.

I was wondering why some of my tests were not passing after a Rake db:test:prepare
Turns out it clears the database, and the only way I have to get it back using the seeds.rb file is with RAILS_ENV="test" Rake db:seed which seems cumbersome and not really railsy at all.

As a bonus, after I run RAILS_ENV="test" Rake db:seed, I then fail a lot of tests. It seems that seeding the test database breaks FactoryGirl's creates.

Is there a way for me to have my seeds and test them?

At the moment I am looking into ways to get seeds.rb to load a FactoryGirl method that I can use to also populate the test database separately. That seems like an easier approach to loading my seeds.rb into FactoryGirl as it causes already passing tests to fail and behave differently in test to development which is obviously bad.

Asking others seemed a good idea:
http://stackoverflow.com/questions/9861075/how-can-i-load-seeds-rb-into-the-test-database-without-breaking-factorygirl

But in the end I managed to weedle out 2 possible answers myself:

1) Loading Seeds from Spec

In Spec/helpers.rb:

def seed_data
require Rails.root.join('db', 'seeds.rb')
end

2) Loading Spec from Seeds

In Seeds.rb

require Rails.root.join('spec', 'helpers.rb')
require 'rubygems'
require 'factory_girl_rails'
seed_data

In Spec/helpers.rb

def seed_data
  Factory.create(:admin)
  #Create all your objects
end

A Newfound Love of Testing

So I will say it from the start, I dislike cucumber with a passion. It just feels like another language I need to write, then I end up writing code to "pass" my tests where I actually end up testing my tests using the code I would have originally wrote.

This meant that all that happened was I sat in the back of lectures thinking "Nope Nope Nope", and that it would just double my work load.
On top of that, cucumber-rails has the added bonus of breaking all machines running windows. Not really an appropriate tool to pick to teach us TDD on windows university PCs with.

Then along came capybara.
The great thing is you can basically write all your tests as variations on a few commands.

• Click_on "some_button_id"
• Page.should have_content  "some #{dynamic} content" 
• visit some_path
• current_path.should eq some_path
• fill_in "field name", :with => "some #{dynamic} content"

That is pretty much it. With capybara, it is like sitting behind someone telling them what to do, it is no longer complicated or cumbersome and your testing doesn't need to be complicated buggy code of its own. It is REALLY simple and I like it. I like it a lot. It even encourages you to make your HTML better documented as if there is a page with a hundred DELETE buttons, you don't want to accidentally click on the one for yourself.

Mix it with Factory_Girl and you are flying in seconds!