Rails 4, a new application: why do tests run in a development environment?

Question

I have a simple, new Rails 4 application that grabs the development database when running rake test:units , although I set RAILS_ENV to test_helper.rb. I would not expect this. Here are the simple steps to play it.

I have Ruby 2.0.0p247 and Rails 4.0.1.

 rails new foo rails generate scaffold gadget rake db:migrate 

I am editing test / models / gadget_test.rb to look like this:

 require 'test_helper' class GadgetTest < ActiveSupport::TestCase test "the env" do assert_equal "test", Rails.env end end 

and I edited the first line of test / test_helper.rb from

 ENV["RAILS_ENV"] ||= "test" 

be

 ENV["RAILS_ENV"] = "test" 

However, when tests invoke rake test:units , this fails:

  1) Failure: GadgetTest#test_the_env test/models/gadget_test.rb:5]: Expected: "test" Actual: "development" 

With the old (Rails 3) applications that I configured, I can count on this to be out of line with the test environment. What am I missing?

Answer 1

The real answer: in the shell of the script that my profile refers to, there was a run export RAILS_ENV="development" . So this is a keyboard interface failure, directly from October 31, 2013 in this thread: https://github.com/rails/rails/issues/7175

All you have to do is take it off and the problem goes away.

Answer 2

The mystery is solved, with a big j_mcnally hat end!

To make Rails env “test” in Rails 4 (and probably much earlier), there’s no need to change the first line of test_helper.rb to

 ENV["RAILS_ENV"] = "test" 

This does not allow reset to cache the value of Rails.env, but if you call

 Rails.env = "test" 

This will reset the cached value correctly. However, there are other places where Rails.env is already being called, otherwise the cache will not be installed. One of the obvious is to install the package in application.rb, where it has Bundler.require(:default, Rails.env) and changing this parameter to Bundler.require(:default, ENV['RAILS_ENV']) (to avoid setting the cache) still indicates that other places in the initialization should also call Rails.env. The significance of all this is that some of the settings will think that it works during the development process, and then the tests will be performed in the "test" environment.

The clean answer is: I have a way to get what I want, but there may be some dangerous places hiding there.

Answer 3

TL; DR make sure the string require 'rails/test_unit/railtie' not commented out in config/application.rb

---

I had the same problem: I tested Minitest as a replacement for TestUnit and generated a Rails application without it ( rails new foobar --skip-test-unit ), but Minitest still uses the test task from rails.

And I had the following code in config/applicaiton.rb :

 # require 'rails/test_unit/railtie' # Require the gems listed in Gemfile, including any gems # you've limited to :test, :development, or :production. Bundler.require(*Rails.groups) 

As j_mcnally and Fitter Man noted, the problem is that Rails.env caches its value before ENV['RAILS_ENV'] set, in my case it is called inside Rails.groups .

Trying to find in Rails sources how it sets the proper test env when invoking a rake task, I find that it does this in rails/test_unit/railtie.rb , which was commented out.

So the solution was as simple as uncommenting the string require 'rails/test_unit/railtie' .

Hope this helps.

Answer 4

As far as I can tell, there should be no reason to force testing Rails.env . Therefore, if you are testing the wrong env, there is something setting env somewhere in your code.

For me, this is caused by the export of env. I did not understand, someone put in the first line of the .rvmc file for the application.

Removing this line export RAILS_ENV=development from this file and restarting the terminal fixed the problem.