Rails 2.3.2 unit test passes when run with normal ruby, fails when run with rake test:units - ruby-on-rails

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.

Related

How to stop rspec from dropping the test database before tests

I have two Rails apps that use the same database. One app is managing the database through migrations but the other is just accessing it.
For some reason when I run tests with RSpec in the app that is not managing the database it drops the database before running the tests. But because this app does not know how to recreate the database all tests will fail.
How can I tell RSpec not to drop the database, just use it as it is?
If you don't need to migrate the database you can redefine rspecs-rails
spec:prepare task like this:
lib/tasks/patch_rspec_rails.rb
Rake::Task["spec:prepare"].clear
namespace :spec do
task :prepare do
ENV['RACK_ENV'] = ENV['RAILS_ENV'] = 'test'
end
end
The original spec:prepare task callstest:prepare, which setups the db.
The task test:prepare exists since Rails 4.0 (or maybe earlier). This task also exists within Rails 5.0. It is a hook for railsties to add test dependent setups. You can check its definition with rake -W test:prepare. That
the task is hit you can check with rake --trace spec.
ActiveRecord uses this task to check the migration state and setup the db.
When this task is not called, no db will be dropped or created.
But be aware, when some other gem uses test:prepare as a hook too plug into tests, it will not work.
Edit:
Since Rails 4.1 you can set config.active_record.maintain_test_schema = false within config/environments/test.rb. This way Rails should no longer try to migrate your test schema.
Ideally RSpec should be reinitialisation the database for testing to ensure your environment is in a reliably, predictable state.
What you could do is for the Rails app that isn't managing the database carry out a rake db:schema:dump to generate the schema.rb which will then be used by RSpec - of course make sure that your database.yml test configuration isn't pointing to your live database.
I know that this isn't technically a solution to your question but it should prevent the underlying issue which is causing your tests to fail.

Load rails fixtures before classes are loaded

I have classes in my Rails project that are 'registered' with attributes read from the database. However, when I run 'rake test', the classes are loaded before the fixtures are created in SQLLite. As a result, the classes are 'registered' with null values, causing my tests to fail.
Manually testing by running my rails server works perfectly fine, so I don't think there is a problem with my code logic. Also, my fixtures are correct.
How can I change the order of loading the fixtures before the classes and models are instantiated.
rake test loads fixtures if you specify fixtures :all. Run rake test --trace to see what happens behind the scenes. I dont think the fixtures are loaded without mentioning fixtures :all
Try to rake db:fixtures:load and see if it raises any error.

Rails remove persisted fixtures from tests

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.

Which one does rspec run first? spec_helper.rb or db:test:prepare

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

Rails 2.3.5 table populated by fixtures at end of test run rather than at start

I start with a test database containing the schema but with no data in the tables. I run a test like so
cd test/
ruby unit/directive_test.rb
I get failures indicating that the code found no data in the data tables. However, I look at the tables after running that test and the data is now in the the table. In fact, if I immediately run the test again I get no failures.
So it appears that the fixture is being loaded into the table too late for one of my modules to find it.
When are the fixtures loaded? After or before the app/model/*.rb files are executed?
If it is after the models are executed is there a way to delay the loading?
This issue is also relevant when running rake test:units since that task clears the test data after it finished.
first of all see this thread and see if it can help you.
if you run the rail task rake test:units it will for sure load all fixtures before you run your code. if you are running just the test, and your unit test has no reference to the test_help.rb probably it is not loading the fixtures. You should try to run it through the rake tasks.
Another tip that i give you is that you forget the fixtures and use factories (here i recommend factory_girl). It takes sometime to get used, but it worth. Fixtures are too hard to manage, update and etc.
there is another post explaing little about the concept behind factories.

Resources