Why should I run rspec specs on my rails app only in a test environment, not dev or prod?

Question

I was told that I shouldn't run my rspec specs in a rails_env other than test.

What are the potential problems running specs in production or development? I run specs in both. I usually run the specs in dev unless I'm testing something that uses the asset pipeline. I switch to production for that and spend 15 minutes pre-compiling assets. Are there any advantages to using the test environment over my current methods?

I searched for an answer but nothing explained why I shouldn't use dev or prod.

Answer 1

Running test suites (such as rspec) in a test environment is intended to isolate resources for security concerns, in particular the integrity of your databases. Tests often corrupt or entirely delete data in your databases.

The same holds true for all resources. By using the test environment you are able to cut off and mock resources, thereby preventing you tests from corrupting anything.

There are many reasons to use separate environments but fundamentally it is a separation of resources, and in the context of the test environment it is to enable the validation of your application while ensuring the safety of the production resources and running system.

Answer 2

Let's be clear, especially for nubes that may be reading this post: RAILS_ENV=production (locally) is not the same as running test "in the production environment." I know you (OP) know that, but the danger of running tests in the production env warrant this warning.

There are several reasons to only run in the test env, generally relating to the handling of the DB:

• Rspec builds a custom 'version' of the data in the DB, and operates upon that, persisting some changes back to the disk.
• Many test wipe out existing data, toward the end of test isolation and making things idempotent. This could wonk-up the data you're using to buildings out in test.

other reasons are along them lines you've surmised already:

1. your prod environment should not include gems that are used for testing. Why?:
   • testing gems add more code that may need ot lod & run, needlessly, in the live app
   • testing-related gems can introduce security holes into your production app.
2. certain assets may not test properly after they are 'compiled'.
3. assets and other deploy-pipe-line precompile can be handled differently / turned off / etc, in service of the testing process.
4. Certain APIs and services may be sandboxed, or stubbed, in test/staging, such as API calls to pay-per-use services, like email or reports.

The possibilities are too-custom (to your app) to suggest a best-practice... but, needless to say, there are many 'test mode' settings that may need configuration when rails_ENV=test