2

I'm writting a rails application by TDD, So, I was wondering, how do I test production app, like having a different security token from development security token, how to ensure that all the configurations are correct in production, like mail configs etc.

Shouldn't we never run tests in production mode, since it would wipe the database.

So, how should one go about testing a rails app in production

Michelle Tilley
  • 157,729
  • 40
  • 374
  • 311
Sathish Manohar
  • 5,859
  • 10
  • 37
  • 47

2 Answers2

8

The method many developers use is creating another environment called stage. You can make your configuration identical to production, and deploy to this before production to ensure everything works correctly. You can run your integration tests / performance tests against staging if you like.

You can copy the production config (config/environments/production.rb) to a new file called stage.rb, then remember to populate your database.yml with the new connection details for a stage database.

Ross
  • 1,551
  • 14
  • 15
1

When you run tests you are always in the test environment since RAILS_ENV is hardcoded in test_helper.rb. Setting RAILS_ENV=production means the schema will be cloned from the production database rather than the development database. I could of course set up a development database on the production servers, but that doesn't seem to make sense.

Given all the differences there are between my development and production server - operating system, web server, database, gems etc. - I can't really feel comfortable deploying my application unless I have first run my test suite not only in development but also in production. Thanks to the beautiful and powerful API of Capistrano this is a walk in the park to accomplish:

Here goes the example how it seems to be done - 

desc "Run the full tests on the deployed app." 
task :run_tests do
 run "cd #{release_path} && RAILS_ENV=production rake && cat /dev/null > log/test.log" 
end

desc "Copy in server specific configuration files"
task :copy_shared do
  run <<-CMD
    cp #{shared_path}/system/voxway.rb #{release_path}/config &&
    cp #{shared_path}/system/database.yml #{release_path}/config
  CMD
end

desc "Run pre-symlink tasks" 
task :before_symlink, :roles => :web do
  copy_shared
  run_tests
end
sjain
  • 23,126
  • 28
  • 107
  • 185
  • 2
    I didn't know that. Are you should you shouldn't set `RAILS_ENV=test` instead? Doesn't it go to the production DB if you put `RAILS_ENV=production`? – Amir Jan 17 '13 at 11:42
  • If you are running tests, then there is no need to set `test` as an environment because by default it is `test` already. In `test_helper.rb`, on top you will see the line- `ENV["RAILS_ENV"] = "test"` doing so purposely. For production, yes you have to set your rails environment to production by `RAILS_ENV=production`. – sjain Jan 17 '13 at 12:04
  • @MyGod I think Amir was saying that testing production with `RAILS_ENV=production` will mix test data with production data, and possibly have negative side effects on the latter. I was thinking of something like using the production env for code, but test for the database... which might be possible be reconfiguring the database config for the test or creating a new environment for this kind of testing.Curious what other best practices are, since I too would prefer to know for sure the tests are successful not just on staging but production. – user8897013 Apr 01 '19 at 09:13