I've created a brand new rails app, added a dummy controller, with an 'assert true' functional test, and an initializer that calls 'puts Rails.env'.
When I run rake test on this app, the initializer prints 'development' and 'test'.
Can anyone tell me why this is?
Peter.
running rake boots up rails, then running your tests (test_helper, spec_helper) loads rails again for the testing environment
if you are using rspec you can invoke it without rake
bundle exec rspec spec
pretty sure with mini-test you can invoke using rake or ruby executable
there should not be any bad side effects running them via rake, just that you need to wait for rails to boot twice
Related
What is the difference between commands rake and rails in Ruby?
Which one is faster and why?
The difference is in what binary is being called.
If you were to call bundle exec which rake within your Rails app root directory, you'd get something like /home/[USERNAME]/.rbenv/versions/2.5.5/bin/rake and for bundle exec which rails, you'd get /home/[USERNAME]/.rbenv/versions/2.5.5/bin/rails. From there you can cat (cat /home/[USERNAME]/.rbenv/versions/2.5.5/bin/rake) both these paths and see similar code is being ran for each, but the end of the files is different.
rails
gem "railties", version
load Gem.bin_path("railties", "rails", version)
rake
gem "rake", version
load Gem.bin_path("rake", "rake", version)
Here they're both calling load on Gem.bin_path but with different arguments, which are attempting to load separate gems in. You can follow the code further by running a irb/pry/rails console, and setting up the needed require 'rubygems' and version = ">= 0.a", then run Gem.bin_path("railties", "rails", version) and Gem.bin_path("rake", "rake", version) to see what the load is actually trying to run. I'll admit it'll become a bit of a rabbit hole before you come across the logic that eventually ends up identifying a rake task argument passed to rails and it proxy's it to Rake and stop there and defer to this SO answer for the rest.
When rails is ran and passed arguments which were intended to be ran by rake, it will attempt to first find if it was an actual argument intended to be given to the rails command, determine that it wasn't, then attempt to run it as a rake command for you for overall naming simplicity added in by the Rails team in Rails v4.
So which is faster to run? rake for actual rake tasks, as it'll bypass the extra logic in needing to determine it was being passed rake arguments. But also rails specific arguments cannot be ran with rake e.g. bundle exec rake generate will not work (unless you have a generate task). If in doubt, run bundle exec rails --help and in at least Rails v5, it'll output which arguments are rails specific and which are rake specific.
rake is a Make-like program implemented in Ruby.
rails is a web framework, which also has some rake tasks.
This means that you can have a ruby program with rake but without rails, but not the other way around.
By itself, rake will be faster because you don't need to load the whole rails application.
But when launching a rake task, it can have dependencies, for example the :environment dependency in a rails app, which tells rake to load the rails environment and quite a bit of your application depending on the current environment.
In this case, the initialization of a rake task may take as long as a rails command.
Please note that the actual task run needs also to be taken into account, it can be very short or take several minutes.
For example, rake db:migrate, which is a rails task available by default, runs the migrations on the database, which can be time-consuming if the database is already populated and/or you have a lot of migrations
In Rails 5.1, you can do bin/rails test to run normal tests, and bin/rails test:system. What is the Rails sanctioned way of running both at the same time?
bin/rails test:system test
Specifying test:system before test will run both system and ordinary tests. The opposite order will only run the ordinary tests however.
rails test:all (Rails 6.1+)
Rails 6.1 introduces a new command - rails test:all.
It runs all test files in the test directory, including system tests.
Here is a link to PR.
And also a link to the docs (please, scroll down to yellow box).
In case anyone else is looking for the answer:
bin/rails test test/*
If it is your intention to run it using just $ rake or $rake test you can add into your Rakefile:
task test: 'test:system'
This will makes 'test:system' a "prerequisites" for "test" task
At least from the official rails guide, it seems there is no way of doing it:
By default, running bin/rails test won't run your system tests. Make sure to run bin/rails test:system to actually run them.
Ref: rails guide
You can also add this snippet in your lib/tasks folder, that will give you the option to do rake test:all
namespace :test do
desc "Run both regular tests and system tests"
task :all => 'test' do
Minitest.after_run {system('rake test:system')}
end
end
Summary of all the answers for easy reference:
System tests Only
bin/rails test:system
Ordinary tests Only
bin/rails test .
ALL tests
bin/rails test:all
I've added gem 'delayed_job' to my gem file and ran a bundle install.
After that I ran rails generate delayed_job
I've created a controller named Online with a method online.
In turn after the method declaration I added the following line:
handle_asynchronously :online
I start up my app, but the code in that method does not run.
What am I doing wrong?
I'd guess that you haven't done rake jobs:work anywhere. From the fine manual:
Running the jobs
You can invoke rake jobs:work which will start working off jobs. You can cancel the rake task with CTRL-C.
You might want to set up Foreman to start the Rails server and the Rake task at the same time in your development environment; there's even a Railscast about it:
http://railscasts.com/episodes/281-foreman
I am creating a brand new full gem plugin using Rails 3.1.0 on ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-linux]. I am having trouble with the schema and fixtures not being loaded for running rake test. Following are the steps I am taking:
Create the plugin:
rails plugin new core --full
From the plugin, generate a new scaffold:
rails g scaffold user
Run the db create and migrate:
rake db:create
rake db:migrate
Run the tests:
rake test
When running the functional tests, I am receiving a set of error like the following from the controller tests:
1) Error:
test_should_create_user(UsersControllerTest):
NoMethodError: undefined method `users' for #<UsersControllerTest:0x00000003babca8>
This error seems to stem from the fact that the test doesn't seem to understand the fixture call. It doesn't look like the test db is getting the schema loaded or having the fixtures loaded. Is this expected behavior? Is there something I'm missing in this scenario? All the fixtures are there. Is there some process I need to follow to get these tests to run correctly?
OK, I think I've made some progress. It looks like I can resolve it with the following changes.
I've added the following to test_helper:
#Run any available migration
ActiveRecord::Migrator.migrate 'up'
# Set fixtures root
ActiveSupport::TestCase.fixture_path=(File.expand_path("../fixtures", __FILE__))
ActiveSupport::TestCase.fixtures :all
This allows the test environment to find my fixtures outside of the dummy application.
After this change, I was still having an issue where the test database was not being prepared for the test. I resolved this by dropping into the test/dummy directory and running:
rake db:test:prepare
After this, I am able to run "rake test" successfully. It's somewhat a pain to have to drop in to the dummy app to prepare the db. There has to be a way around this. Any suggestions?
The background: I'm having some problems with Thoughtbot's "Factory Girl" gem, with is used to create objects to use in unit and other tests. I'd like to go to the console and run different Factory Girl calls to check out what's happening. For example, I'd like to go in there are do...
>> Factory(:user).inspect
I know that you can run the console in different environments...
$ script/console RAILS_ENV=test
But when I do that, Factory class is not available. It looks as though test_helper.rb is not getting loaded.
I tried various require calls including one with the absolute path to test_helper.rb but they fail similarly to this:
$ script/console RAILS_ENV=test
>> require '/Users/ethan/project/contactdb/test/test_helper.rb'
Errno::ENOENT: No such file or directory -
/Users/ethan/project/contactdb/config/environments/RAILS_ENV=test.rb
Grr. Argh.
For Rails < 3.0
Run script/console --help. You'll notice that the syntax is script/console [environment], which in your case is script/console test.
I'm not sure if you have to require the test helper or if the test environment does that for you, but with that command you should at least be able to boot successfully into the test env.
As a sidenote: It is indeed kind of odd that the various binaries in script/ has different ways of setting the rails environment.
For Rails 3 and 4
Run rails c test. Prepend bundle exec if you need this for the current app environment.
For Rails 5 and 6
Run rails console -e test.
In Rails 3, just do rails console test or rails console production or rails console development (which is the default).
For Rails 5.2.0: "Passing the environment's name as a regular argument is deprecated and will be removed in the next Rails version. Please, use the -e option instead."
rails c -e test
script/console test
Should be all you need.
You can specify the environment in which the console command should operate.
rails c [environment]
Examples
1) For Staging
rails c staging
2) For Production
rails c production
For source & detailed description: The Rails Command Line
David Smith is correct, just do
script/console test
The help command will show why this works:
$ script/console -h
Usage: console [environment] [options]
-s, --sandbox Rollback database modifications on exit.
--irb=[irb] Invoke a different irb.
--debugger Enable ruby-debugging for the console.
It's the [environment] bit.
I share the asker's pain. There are really three separate questions here, some of which are addressed, some not:
How do you start the console in the test environment?
For recent Rails versions, bundle exec rails c test, or alternative syntaxes for that.
How do you ensure that test/test_helper.rb is loaded into that console session?
Something like require './test/test_helper' ought to do it.
For me, this returns true, indicating that it was not already loaded when I started the console. If that statement returns false, then you just wasted a few keystrokes, but you're still good to go.
Once test_helper is loaded, how do you call the methods defined in it?
In a typical test_helper, the custom methods are typically defined as instance methods of ActiveSupport::TestCase. So if you want to call one of them, you need an instance of that class. By trial and error, ActiveSupport::TestCase.new has one required parameter, so...pass it something.
If your test_helper has a method called create_user, you could invoke it this way:
ActiveSupport::TestCase.new("no idea what this is for").create_user
Make sure you installed the GEM and you added the following line either in your environment.rb or test.rb file.
config.gem "thoughtbot-factory_girl", :lib => "factory_girl", :source => "http://gems.github.com"
Test Env
rails console test # or just rails c test
Developement Env
rails console # or just rails c
Command to run rails console test environment is
rails c -e test
or
RAILS_ENV=test rails c
if you are facing problem something like
ActiveRecord::StatementInvalid:
Mysql2::Error: Table 'DB_test.users' doesn't exist: SHOW FULL FIELDS FROM `users`
then you should first prepare your test DB by running
bundle exec rake db:test:prepare