I'm trying to perform an integration test via Watir and RSpec. So, I created a test file within /integration and wrote a test, which adds a test user into a base via factory_girl.
The problem is — I can't actually perform a login with my test user. The test I wrote looks as following:
...
before(:each)
#user = Factory(:user)
#browser = FireWatir::Firefox.new
end
it "should login"
#browser.text_field(:id, "username").set(#user.username)
#browser.text_field(:id, "password").set(#user.password)
#browser.button(:id, "get_in").click
end
...
As I'm starting the test and see a "performance" in browser, it always fires up a Username is not valid error.
I've started an investigation, and did a small trick. First of all I've started to have doubts if the factory actually creates the user in DB. So after the immediate call to factory I've put some puts User.find stuff only to discover that the user is actually in DB. Ok, but as user still couldn't have logged in I've decided to see if he's present in DB with my own eyes.
I've added a sleep right after a factory call, and went to see what's in the DB at the moment. I was crushed to see that the user is actually missing there! How come? Still, when I'm trying to output a user within the code, he is actually being fetched from somewhere. So where does the records, made by factory_girl within a runtime lie? Is it test or dev DB? I don't get it.
I've 10 times checked if I'm running my Mongrel in test mode (does it matter? I think it does, as I'm trying to tun an integration test) and if my database.yml holds the correct connection specific data.
I'm using an authlogic, if that can give any clue (no, putting activate_authlogic doesn't work here).
Don't forget that RSpec is probably using transations when running the specs. RSpec will wrap the execution of the spec within a transaction and rollback at the end. It means you won't be able to see the record from outside that transaction (i.e. from another SQL connection).
If you want to ensure the user record is actually created by Factory Girl, you can do something like:
before(:each)
#user = Factory(:user)
User.find_by_username(#user.username).should_not be_nil
#browser = FireWatir::Firefox.new
end
Somehow the solution went strange — I put factories to before(:all) block, and all the stuff worked as it should.
Factory Girl is going to create temporary DB entries in your test database. Your tests database is going to be cleared out after each test.
Related
In Rspec, I'm creating records, e.g. let!(:user) { create(:user) }.
I can access the new user in Rspec and in the main thread of the subject. Both of these return the user:
puts User.all.to_a
puts ActiveRecord::Base.connection.exec_query('select * from users')
However, I can now longer access the user in a new thread:
Thread.new do
puts User.all.to_a
puts ActiveRecord::Base.connection.exec_query('select * from users')
end
How do I fix this? Is this just an Rspec issue? I don't think I can reproduce it in Rails console.
You have probably configured RSpec to run its test within a database transaction
Quote from the RSpec Docs:
>
When you run rails generate rspec:install, the spec/rails_helper.rb file
includes the following configuration:
RSpec.configure do |config|
config.use_transactional_fixtures = true
end
The name of this setting is a bit misleading. What it really means in Rails
is "run every test method within a transaction." In the context of rspec-rails,
it means "run every example within a transaction."
The idea is to start each example with a clean database, create whatever data
is necessary for that example, and then remove that data by simply rolling back
the transaction at the end of the example.
You might want to disable this configuration when your application tests have the requirement to support multiple threads at the same time.
But that means that your test database will not be cleared from test data automatically anymore when a test is done. Instead, you will need to delete the test data manually or use another gem (like database_cleaner) to reset the database after running tests.
I'm having an issue with my specs. I'm trying to run a spec that creates and destroys an associated object, but none of my specs are creating or destroying that object. The weird thing is, I can literally copy and paste every line of code (except for the .should) out of each test into the console and the console will run each expectation perfectly, creating and destroying those objects. Here's a sample:
it "should not destroy notification for like on comment" do
comment = FactoryGirl.create(:comment)
like = FactoryGirl.create_list(:like, 2, likable: comment)
like.first.destroy
note = comment.user.notifications.find_by(notifiable: comment, from_comment: false)
note.should_not be_nil
end
Only the first like on a specific comment will send a notification to that comment's author. And if a comment only has one like, and that like is destroyed, it will destroy the notification it had originally sent, but it won't destroy the notification if the comment has more than 0 likes at any time.
Is the problem that I'm just not writing scalable code? I know my specs probably aren't perfect, but why is the console getting different results with identical input?
Are you running your rails console in test environment or in development as it defaults to?
Different database and environment configurations might be the reason for different behavior, also the note object might already exist in development db at the time you test it manually in console.
Either try running console in test environment:
$ rails c test
or better temporarily put debugger line inside your test code (you will need get 'debugger' gem installed if don't have it already):
it "should not destroy notification for like on comment" do
comment = FactoryGirl.create(:comment)
like = FactoryGirl.create_list(:like, 2, likable: comment)
debugger
like.first.destroy
note = comment.user.notifications.find_by(notifiable: comment, from_comment: false)
note.should_not be_nil
end
I have the following code in a spec:
it 'should save some favorite locations' do
user=FactoryGirl.create(:user) # not adding anything
and it doesn't seem to write anything to the database. Is FactoryGirl intended to write something with this in a model spec? If I run from the rails console, it does add to the database. Why isn't a test in an rspec isn't running this? Is that how it is intended to work?
thx
If you have configured rspec to use database transactions for each test, or to use database truncation, then any records created are rolled back or destroyed.
To check that it really is adding something, you could try:
it 'should save some favorite locations' do
user=FactoryGirl.create(:user) # not adding anything
User.find(user.id).should_not be_nil # ensure it is in database
If it passes, then it was added to the database.
If you are using database transactions for your tests, then the database is rolled back after each test. If you need to use a record which is created in multiple tests, you can use:
before(:all) do
#user=FactoryGirl.create(:user)
end
after(:all) do
#user.destroy # with create in before(:all), it is not in a transaction
# meaning it is not rolled back - destroy explicitly to clean up.
end
I'd like to init the data base once everytime i run tests, rather than every test.
I know with Rspec there is before(:all), but I haven't been able to get that working. I was wondering if rails had something similar.
Firstly: there used to be a before(:all) equivalent in Test::Unit but it was removed (don't know why).
Secondly: there are very good reasons not to do what you are trying to do - tests are meant to be run independently of one another, not rely on state that's in the db. This way you can guarantee that it's testing exactly what you are expecting it to test.
If you have one test that changes the state of the db, and you move it and it runs after another test which expects it to be another state - you run into problems. Thus, all test must be independent.
Thus: the db is rolled back to its pristine state and re-seeded every time.
If you really want some state that the db is always in - then set it up in the fixtures... and just realise that the db will be re-loaded for each test.
If you are having trouble with load-times... then consider figuring out some other way around the problem - eg don't use huge numbers of fixtures, instead use Factories to only create the data that you need for each individual test.
If there's some other reason... let us know - we may have a solution for it.
Edit: if you really need it, I actually wrote a monkey patch for this a long while back:
"faking startup and shutdown"
All things to run before everything just go in the top of the class
require 'test_helper'
class ObjectTest < ActiveSupport::TestCase
call_rake("db:bootstrap RAILS_ENV=test")
#set up our user for doing all our tests (this person is very busy)
#user = Factory(:user)
#account = Factory(:account)
#user.account = #account
#user.save
# make sure our user and account got created
puts "||||||||||||||||||||||||||||||||||||||||||||||"
puts "| propsal_test.rb"
puts "| #{#user.name}"
puts "| #{#user.account.name}"
puts "||||||||||||||||||||||||||||||||||||||||||||||"
I've been trying to solve a problem for a few weeks now. I am running rspec tests for my Rails app, and they are working fine except for one error that I can't seem get my head around.
I am using MySQL with the InnoDB engine.
I have set config.use_transactional_fixtures = true in spec_helper.rb
I load my test fixtures manually with the command rake spec:db:fixtures:load.
The rspec test is being written for a BackgrounDRb worker, and it is testing that a record can have its state updated (through the state_machine gem).
Here is my problem:
I have a model called Listings. The rspec test calls the update_sold_items method within a file called listing_worker.rb.
This method calls listing.sell for a particular record, which sets the listing record's 'state' column to 'sold'.
So far, this is all working fine, but when the update_sold_items method finishes, my rspec test fails here:
listing = Listing.find_by_listing_id(listing_id)
listing.state.should == "sold"
expected: "sold",
got: "current" (using ==)
I've been trying to track down why the state change is not persisting, but am pretty much lost. Here is the result of some debugging code that I placed in the update_sold_items method during the test:
pp listing.state # => "current"
listing.sell!
listing.save!
pp listing.state # => "sold"
listing.reload
pp listing.state # => "current"
I cannot understand why it saves perfectly fine, but then reverts back to the original record whenever I call reload, or Listing.find etc.
Thanks for reading this, and please ask any questions if I haven't given enough information.
Thanks for your help,
Nathan B
P.S. I don't have a problem creating new records for other classes, and testing those records. It only seems to be a problem when I am updating records that already exist in the database.
I suspect, like nathan, transaction issues. Try putting a Listing.connection.execute("COMMIT") right before your first save call to break the transaction and see what changes. That will break you out of the transaction so any additional rollback calls will be non-effectual.
Additionally, by running a "COMMIT" command, you could pause the test with a debugger and inspect the database from another client to see what's going on.
The other hypothesis, if the transaction experimentation doesn't yield any results, is that perhaps your model really isn't saving to the database. Check your query logs. (Specifically find the update query).
These kind of issues really stink! Good luck!
If you want to investigate what you have in DB while running tests you might find this helpful...
I have a rspec test where I save #user.save and it works like a charm, but then I wanted to see if it's really saved in the DB.
I opened rails console for test environment
rails c test
ran
User.all
and as expected got nothing
I ran my spec that contains:
user_attr_hash = FactoryGirl.attributes_for(:user)
#user = User.new user_attr_hash
#user.save
binding.pry
I thought that stopping the test after save would mean that it's persisted, but that's not the case. It seems that COMMIT on the connection is fired later (I have no idea when:\ )
So, as #Tim Harper suggests, you have to fire that commit yourself in the pry console:
pry(#<RSpec::Core::ExampleGroup::Nested_1>)> User.connection.execute("COMMIT")
Now, if you run User.all in your rails console you should see it ;)