I'm trying to implement an additional check for faulty database.yml configurations. In our configuration, we follow the rails database.yml convention, which is basically adding "_#{env}" suffix to the names of the databases. We've had an incident on another project (not rails), where someone forgot to switch databases before running unit tests, causing us to lose data on the staging environment. We hacked a workaround by adding a simple check, which is: if the database name doesn't end with "_test", don't wipe it, don't run unit tests on it.
So what is the right way of implementing this check for rails. I figured I can do it in the spec_helper.rb, but when I ran the tests after I changed the database name, instead of raising the error message that I wrote, it threw:
TinyTds::Error: Database 'some_db_name' does not exist. Make sure that the name is entered correctly.
Which means, it connected to the db before spec_helper.rb is loaded. I couldn't find any information on when the db:test:prepare is executed, and didn't ahve the courage to test it with an existing db that doesn't have "_test" suffix.
Is there a hook that I can use for this?
Including in your spec_helper.rb
ENV["RAILS_ENV"] = 'test'
line the rspec test should run in test environment looking for test database connection string and therefore run always in test database. Without any problem for others differents environment databases
Related
“I have a Rails application with PostgreSQL database. My database contains 1000 records in it.
I have written a rake task which will manipulate the records in the database.
If the rake task went wrong i want to revert back the changes to the original in the database.
is there any chance of testing the database in this scenario without duplicating the database in the development environment ?”
In Rails itself having the feature sandbox
If you wish to test out some code without changing any data, you can do that by invoking rails console --sandbox.
bin/rails console --sandbox
Loading development environment in sandbox
Any modifications you make will be rolled back on exit
irb(main):001:0>
You can paste your ruby code here and can see the changes you wanted to see. while closing this console, All your changes will be reverted back(running as a transactional)
For more informations you can refer this link
http://edgeguides.rubyonrails.org/command_line.html#rails-console
you can duplicate a database in same env.
create database test with template original_db;
Will create cop of existing db, on which you can run your tests, specifying test instead of original db name in connections string
I know that generally you want your test suite to run against a freshly configured set of data each time tests are run. However, I have a site with a fairly set of static data. Is it possible to have my tests run against my local db that has been populated from my production database? I have this DB configured in my database.yml file, however the db gets blown away each time a I run tests, and I'd like it to remain static.
Is this possible with rspec?
With the database_cleaner gem, you can limit which tables get truncated:
https://github.com/DatabaseCleaner/database_cleaner#how-to-use
Did not need database_cleaner gem. Turns out I was running rake spec which was truncating my DB each time. Instead if I run rspec spec the DB is NOT truncated.
I used to have 3 fixtures in my RSpec tests. I have removed them and went with the FactoryGirl approach. The problem is that, when I run my tests, even though I have no trace of fixtures left, they still appear when running the tests.
If I debug the tests, I can see that the fixtures' creation date is old, older than the objects created when running the current test.
I believe fixtures are somewhere cached, how can I clear this cache? Or, if this is not the case, why are the old fixtures there when running the tests?
rake db:setup will reload your test database from your schema.rb, erasing your fixture data.
After some deep digging, I found out that some sourced files were setting an env var with the development db, not the test db. Pretty trivial mistake, but so hard to find.
As a conclusion, if others stumble upon weird problems like this one, be sure to check whether you are using the right environment variables/configuration options in your app.
I'm using postgresql on a rails 3 app. I've been using sqlite3 for test environment, but decided to finally switch to the same db I use in production for testing purposes. Problem is, I'm only creating one database and diverse schemas for each environment. This is somethiing I can't change, since the environment is enterprise-constrained.
Hence, I have a test schema. I rund db:schema:load on it and it works fine. I run rake spec on it (I'm using rspec) and it breaks, exactly on the 'db:test:purge' task which comes from rails. Now, this task drops the database. Not only is the database owner different from the schema owner in my case, I'd rather have the task recreate the schema instead of recreating the database.
How can I do this?
Actually there is no real solution for this problem, since rails by default erases the database. It expects this database not to be shared with production (and they might have a point). Nevertheless, I found some interesting links and the way is to patch the rake task. Following the patch and links:
namespace :db do
namespace :test do
task :purge do
ActiveRecord::Migration.verbose = false
Rake::Task["db:schema:load"].invoke
end
end
end
https://github.com/rails/rails/issues/12117#issuecomment-25961999
Run Rails Tests without Dropping Test Database
http://www.pervasivecode.com/blog/2007/09/22/making-rails-raketest-not-drop-your-pgsql-database/
This is not a direct answer to your question, but you can use rspec command instead of rake spec. rspec command doesn't purge your database.
When creating a record in a unit test, I'm getting an 'ActiveRecord::RecordInvalid' when it's run with rake test:units. I don't get this error when I run the unit test manually with ruby ('ruby unit/blah_test.rb'). I've narrowed the issue down to a validation that exists in my model. It is an inclusion validation which is actually performing a find against a different model to get the valid values. I'm thinking this is related to the fixtures not being loaded in time, but I do have 'fixtures :all' in my test_helper.rb (I've also tried including 'fixtures :all' in the unit test itself.
Does anyone have any suggestions on how I can try to narrow this down even further?
Thanks.
Certainly what you are seeing would fit with fixtures being missing. With rake test:units the test database schema will be set up (and cleared) so your included model's fixtures may not be populated. With the direct call you'll be using the test database in the state you last left it which probably does include the fixutres for the included model.
Is there another call to fixtures in the test class which may be causing fixtures :all not to kick in?
You could try doing rake db:test:prepare prior to running your test via ruby which would mean you were running on a fresh test database. This would further highlight if the fixtures aren't being loaded for your included model.