I have an application that I'm testing with rspec2 (2.6.4), capybara and selenium.
When I run any request spec directly with rspec, the test passes.
When I run the request specs with autotest they all fail with a message saying 'Cannot find a User with ID= **.
When autotest reloads the first request test automatically, it passes
Autotest then reloads all tests and when it reaches the request tests they all fail again
Users are being created by factory-girl and logged in using devise as follows:
before(:each) do
#user = Factory(:user)
login_as #user
end
after(:each){
logout
}
and in the spec helper I have
def login(user)
post login_path, :login => user.login, :password => 'testing'
end
These are the relevant gems i have installed (group :test)
gem "rspec"
gem "rspec-rails"
gem "autotest-rails"
gem "selenium-webdriver", ">= 0.2.2"
gem 'capybara', :git => 'git://github.com/jnicklas/capybara.git'
gem 'launchy'
gem 'database_cleaner'
This has been baffling me for a while now - any thoughts anyone? Even any thoughts on how to start looking at the stack trace to see where the two calls are differing?
Solved, sort of. What is really going on here remains a mystery, but here is an accurate summary of what the problem really is, and how I resolved it. Autotest is not the culprit - the problem is running all the tests in one batch. Running rspec spec/**/* causes the same error. This is a clue that the issue is to do with a failure to clean up the database properly between tests. I am using devise, and so am ultimately relying on warden for rack-based authentication. Following the Warden documentation I put a call to Warden.test_reset! in the after(:suite) block. If I move this to the after(:all) block, the tests pass the same whether run individually, as request tests, or all the tests in one block.
So what did we learn? I think the problem (for me at least) was ultimately caused by a confusing naming of the rspec hooks. I think of a "suite" of rooms in a hotel as being less than "all" the rooms in a hotel. But apparently a "suite" of rspec examples is more than "all" the examples. In fact a suite of rspec examples is just "all the examples under the spec directory". Cleaning up warden after they have all been run has no effect. We need to clean them up after each spec - and to do that need to run test_reset! in the after(:all) block.
Hope this helps someone ...
Related
I'm writing a piece of test code for my Rails 4 app, and I was wondering if there's a way to automate it in order to submit a URL to the web every time its run.
Typing a specific URL (http://website.com/add?application=Test&...&severity=ERROR) into a browser search bar populates my database with certain data, and I want to test if changing the parameters of the URL yields the correct results. Is there a way to make my test code do this by itself?
You need 2 gems:
faker for generating random stuffs like email addresses, names, phone numbers, etc.
rspec-rails, a test automation tool for Ruby on Rails.
There will be some configuration to enable these things. Since you are an intern, I give you a minimum sample.
In the following steps, the path / refers to the root of your rails application, not the root of the file system.
Step 1: install these gems
In the /Gemfile, add these lines:
group :test do
gem 'rspec-rails'
gem 'faker'
end
Then run bundle install.
After the gems are installed, run rails generate rspec:install, which generates the folder /spec/ and some files in it.
Step 2: write tests
Finally you can write tests.
Run rails generate rspec:request add, it will give you a test script file at /spec/requests/adds_spec.rb. It looks like
require 'rails_helper'
RSpec.describe "Adds", type: :request do
describe "GET /adds" do
it "works! (now write some real specs)" do
get adds_path
expect(response).to have_http_status(200)
end
end
end
Now modify it
require 'rails_helper'
RSpec.describe "Add", type: :request do
let(:application) {Faker::Lorem.word}
let(:severity) {%w(trace debug info error fatal).sample}
# other params ...
describe "GET /add" do
it "creates some record" do
get add_path(application: application, severity: severity)
my_model = MyModel.last!
expect(my_model.application).to == application
# other expectations ...
end
end
end
Then run it with bundle exec rspec spec.
P.S. You may need database_cleaner to clean up database after each test. You may also need factory_girl_rails to help you create fixtures. You may need capybara to mimic human using browsers. You may ... So find yourself a textbook about Rails.
Working on a new Rails 3.2.9 app with rspec and capybara.
I have the following in the Gemfile:
gem 'rspec-rails'
gem 'capybara'
and the following in spec/spec_helper.rb:
require 'rspec/rails'
require 'capybara/rspec'
and in spec/requests/asdf_spec.rb:
require 'spec_helper'
describe 'Asdf' do
describe "GET /asdfs" do
it "should list asdfs" do
visit asdfs_path
end
end
end
This test is failing:
Failure/Error: visit asdfs_path
NoMethodError:
undefined method `visit' for #<RSpec::Core::ExampleGroup::Nested_1::Nested_2::Nested_1:0x007fa7b68961a0>
# ./spec/requests/asdfs_spec.rb:19:in `block (4 levels) in <top (required)>'
So it looks like Capybara isn't getting loaded. Ack, why not? I feel like I've done this exact same thing a dozen times before... probably blanking on something stupid.
So it was a capybara version 2 change. I found this:
http://alindeman.github.com/2012/11/11/rspec-rails-and-capybara-2.0-what-you-need-to-know.html
which explains:
Upon upgrading to capybara 2.0, capybara will not be available by
default in RSpec request specs. Instead, a new type of spec--the
feature spec--has been created for use with capybara.
To upgrade to capybara 2.0, you'll need to do a few things:
Upgrade rspec-rails to 2.12.0 or greater
Move any tests that use capybara from spec/requests to spec/features. Capybara
tests use the visit method and usually assert against page.
Just some additional info for anybody having the same problem with the Capybara upgrade to 2.x. Check out rspec-rails docs under the Upgrading to Capybara 2 section.
Basically, In order to use the Capybara DSL(page & visit) you must move your existing specs into the spec/features directory. So you can only use page & visit in acceptance tests. No more page & visit in controller and request specs. Only the rack-test DSL (get|post|put|delete|head/response.body) is allowed in controller and request specs.
This is not recommended but there is a way to keep your specs working as they are:
RSpec.configure do |c|
c.include Capybara::DSL, :example_group => {
:file_path => "spec/requests"
}
end
The docs state that if you go this route then you are overriding the intended behavior and you are taking a risk.
And definitely don't make this as a reason not to upgrade to Capybara 2.x. Feature specs are easy to get used to and are easy to read. feature is just an alias for describe, background is an alias for before, scenario for it, and given for let.
Hope this helps anyone confused by the new changes.
The issue is in capybara gem itself.
gem 'capybara', '1.1.2' solves this issue ( Version 2.0.x fails )
I've got a few tests running with RSpec for a Rails site, but despite
following the instructions things aren't quite behaving themselves.
I create an article via a Factory, run Sunspot.commit and then check
the results. I always seem to draw a blank though. When I test it
manually via the console or through the website it all works find
though.
Any ideas? How can I output the sunspot logs to see what's going on?
My Gemfile has the following, and I'm running Rails 3.1.1
gem 'sunspot', '1.2.1'
gem 'sunspot_rails'
gem 'sunspot_test'
Many thanks,
Graeme
It was my fault for not reading the manual properly.
https://github.com/collectiveidea/sunspot_test/issues/9
It's necessary to add a magic bit to the description to make sure that Solr is started.
describe "my nice test", :search => true do
thing = Factory.create(:thing)
Sunspot.commit
# do my search and test
# now it works!
end
It's the :search => true that's important.
Just to add a little something to the response above; if using FactoryGirl:
FactoryGirl.define do
after(:create) { Sunspot.commit }
...
end
then you won't have to add the commit call on each test file...
I've been using Capybara for integration/request testing, but have only just realised I can't do view testing with it.
This SO answer suggests Webrat and Capybara can be used in tandem; but the RSpec docs suggest one must choose between the two. Here's another github thread that suggests webrat can be used for views and capybara for integration.
I've found that if I include Webrat in my gemfile, I can use webrat for views with no problem, but my capybara-styled integration tests no longer work. Specifically, I get an error with the following simple example:
it "should have a Home page at '/'" do
visit '/'
page.should have_selector('title', :content => "Home page")
end
I get the error:
No response yet. Request a page first.
What's the best way (if any?) to get webrat and capybara to like eachother?
There's generally no reason to use both Webrat and Capybara. Pick one (probably Capybara). View tests are a bad idea and shouldn't be necessary in general; usually your integration tests should cover that ground.
In other words, fix your testing strategy and the problem will go away.
In general, I agree with Marnen about "just pick one of them, probably Capybara", but one possible reason to use both of them is gradual migration.
Say, you have a large test suite and you're migrating it to Capybara, but you'd like to let some of your old tests to stay "Webrat-driven" for some time.
Although, I didn't find ideal solution for this case, here's what I did:
# features/support/env.rb
...
if ENV['WITH_WEBRAT'].nil?
require 'capybara/rails'
require 'capybara/cucumber'
...
else
require 'webrat'
...
end
...
# config/cucumber.yml
...
default: --profile capybara
capybara: <% std_opts %> --tags ~#webrat features
webrat: <% std_opts %> --tags #webrat features WITH_WEBRAT=1
...
# features/webrat.feature
#webrat
...
# features/capybara.feature
...
Now, you can do cucumber to run your capybara-only test suite or cucumber -p webrat for your legacy Webrat features.
Not ideal, but it worked for me.
I'm trying to set up Factory Girl with Test::Unit and Shoulda in Ruby on Rails. I have installed the gem, created my factory file under the test/factories directory, and created my spec file under the test/models directory. The current error I'm getting is 'ArgumentError: No such factory: test', which leads me to believe that the test_factory.rb file is not being loaded? Any idea as to what I should change?
Here are my files.
#test/factories/test_factory.rb
Factory.define :test do |t|
t.name 'test_spotlight'
t.label 'test spotlight label'
end
and
#test/modes/test_spec.rb
require 'test_helper'
require 'factory_girl'
class TestTest < Test::Unit::TestCase
def setup
#test = Factory.build(:test)
end
context "A test" do
should "save with the minimum requirements" do
assert #test.save
end
end
end
I've run into this problem on one of my projects too. I'm not sure precisely what's causing the initialization code to be skipped but you can force load the factory definitions like this:
require 'factory_girl'
Factory.find_definitions
Hope this helps.
Try putting this in test_helper.rb:
require 'factory_girl'
Dir.glob(File.dirname(__FILE__) + "/factories/*").each do |factory|
require factory
end
Just discovered factory_girl_rails, where it says the autoloading is the only extra thing it has https://github.com/thoughtbot/factory_girl_rails
I had the same problem. Eventually I made do by putting all my factories in "/test/factories.rb" and writing the following lines in my "/test/test_helper.rb" file:
require 'factory_girl'
require File.dirname(__FILE__) + "/factories"
you could do the same thing for multiple files by requiring them in the test_helper. I haven't yet figured out why the auto-include that's mentioned in "factory_girl's" readme doesn't happen.
I also managed to get rid of this issue by putting this line into my environment.rb:
config.gem "factory_girl", :source => "http://gemcutter.org"
Make also sure you have the latest gem:
Name changed from "thoughtbot-factory_girl" to "factory_girl", source changed from "http://gems.github.com" to "http://gemcutter.org".
In case you had this issue with ruby 1.9.2, require expects the expanded path.
File.expand_path("test/factories.rb")
This patch solved my problem. I just sent a pull request.
After that you can add this to your test_helper.rb:
require 'factory_girl'
FactoryGirl.find_definitions
If I only required 'factory_girl' in test_helper.rb, I would get the same behavior you mentioned, yet if I required it in my config/test/environment.rb (note I use environmentalist) it would properly find the Factory definition without any issue.
I tried this after reading the factory girl rdoc where it says to put config.gem in your environment.
I also ran into the problem - after updating FactoryGirl to 1.3.2 - that factories from test/factories were not loaded automatically any more.
I could get rid of the problem by adding the code from dg into test_helper.rb:
Dir.glob(File.dirname(__FILE__) + "/factories/*.rb").each do |factory|
require factory
end
When running single tests in Textmate, everything worked fine, but running e.g. all unit tests from the command line using rake test:units failed with a DuplicateDefinitionError (I read that it has probably something to do with ruby 1.8.x). So I slightly changed the code:
if (!Factory.factories || Factory.factories.empty?)
Dir.glob(File.dirname(__FILE__) + "/factories/*.rb").each do |factory|
require factory
end
end
Have you tried moving the
require 'factory_girl'
to your test/test_helper.rb ?
The factory auto-loading mechanism may depend on where the the require is called. It could be trying to find factories *test/models/factories/** instead of *test/factories/**
Instead of naming your factory file test_factory.rb, try naming it factory.rb
Interesting. I had a similar problem trying to get cucumber to work with factory_girl. I had originally configured factory_girl to be looked for ('config.gem') but not loaded in the cucumber environment and fully required in 'features/support/env.rb', same as cucumber does for webrat, etc. That only started to work when I explicitly told factory_girl to find its definitions as Kenny suggested above.
When I removed the require statement from env.rb and fully required factory_girl in the cucumber environment, the effect went away and factory_girl worked out of the box.
So it really seems to be a question of when (or in which context) factory_girl gets loaded.
Since different people are using different versions of Rails (2.x and 3.x being the most common now), it is important to include the other pertinent pieces of your environment (the most important being which version of Rails you're on). From the factory_girl web page, version 1.3.0 documentation (http://rubydoc.info/gems/factory_girl/1.3.0/frames):
If you want to use factory_girl with Rails 3, use the
factory_girl_rails gem, not this one.
If you want to use factory_girl with Rails versions prior to Rails 3,
use version 1.2.4.
If you're having trouble with the loading, I'd suggest making sure that you are using the right version. The versions of factory_girl greater than 1.2.4, I'd assume, are brought in as dependencies for the 'factory_girl_rails' (Rails 3.0+) gem.
I added
require 'factory_girl'
require File.dirname(FILE) + "/factories"
to spec_helper.rb whiche helped, but then I rememberd Spork can sometimes ba a bit of a problem, so I restarted Spork without the require and then it worked fine.