Why not to test everything with Capybara

Firstly, I like Capybara. I think it is nice how easy it is to test with just a few verbs, and you can do things from the perspective of the user. It is no good having the back end for a feature if nobody is ever going to click the button to make it happen. I decided to try do an entire project using just Capybara for testing.

However this comes at a price. Each assertion restarts Rails Server.
This is VERY slow for lots of tests to the point where each test takes about 2 seconds in my current project.

I suppose a drawback some people might make is my tests are tightly bound to the actual view which is another drawback of using Capybara.

Yet another issue I am hitting is organization, all my Capybara tests end up in the same Requests folder which is quite naughty of me.

So, Capybara is slow on many assertions, it links you to the way you display information, and it makes me personally use a disorganised file structure.
Conclusion is I should not use entirely Capybara for the entire project testing. I really need to mix Rspec in there with occasional sprinkles of Capybara.

Something about TDD I never expected.

There is one thing I have always thought about programming, is that to do it, you need a couple of hours and to sit down and get in the zone. You really have to settle in and let it absorb you.

This is a bit of a problem when you have just an hour or less to spare because you know just as you actually get what the piece of code does, you need to give up and set off.

However, with test driven development, I can sit down, run bundle exec guard (A gem that runs all my specs for me when a file changes) and if I finished last while writing spec, I will put a spoof method like ENDED_HERE in the code, and it will flash up, or if tests fail, then I can jump straight to the piece of code that breaks.
I can sit down for just 10 mins at a time and make it pass a couple lines of spec and push up the code and go to work/lunch/friends/pub as needed.

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!