What is the best way to write specs for code that depends on environment variables?

Question

I am testing some code that pulls its configuration from environment variables (set by Heroku config vars in production, for local development I use foreman).

What's the best way to test this kind of code with RSpec?

I came up with this:

before :each do
    ENV.stub(:[]).with("AWS_ACCESS_KEY_ID").and_return("asdf")
    ENV.stub(:[]).with("AWS_SECRET_ACCESS_KEY").and_return("secret")
end

If you don't need to test different values of the environment variables, I guess you could set them in spec_helper instead.

This works the same with Mocha: `ENV.stubs(:[]).with("AWS_ACCESS_KEY_ID").returns("asdf")` — jeradg, Oct 03 '14 at 13:59
@jeradg, but you can't access any other variable in this way :/ — akostadinov, Mar 08 '23 at 20:14

score 95 · Answer 1 · edited Nov 17 '14 at 13:50

95

You also can stub the constant:

stub_const('ENV', {'AWS_ACCESS_KEY_ID' => 'asdf'})

Or, if you still want the rest of the ENV:

stub_const('ENV', ENV.to_hash.merge('AWS_ACCESS_KEY_ID' => 'asdf'))

edited Nov 17 '14 at 13:50

Fabio

18,856
9
82
114

answered Nov 13 '13 at 10:45

iGEL

16,540
11
60
74

3

`ENV` doesn't appear to have a `merge` method (at least in Ruby 1.9.3). – David Tuite Aug 27 '14 at 12:26
1

This is the best approach for a quick env stubs, but in second case you need `ENV.to_hash` to preserve original env. – Fabio Nov 17 '14 at 13:51
Making the hash keys double quoted made it work for me. When i had the keys with single quotes, they got converted to :symbols. Ex: :AWS_ACCESS_KEY_ID – Pratik Khadloya Sep 15 '15 at 05:57

score 29 · Accepted Answer · answered Mar 08 '12 at 00:42

29

That would work.

Another way would be to put a layer of indirection between your code and the environment variables, like some sort of configuration object that's easy to mock.

answered Mar 08 '12 at 00:42

nicholaides

19,211
12
66
82

2

If this is in Rails you already have its own configuration object to add to if you want. – Andrew Marshall Mar 08 '12 at 00:49
3

That is a handy tip. I did not know you could define your own configuration options so easily. Just do this in environments/*.rb: `config.my_config_value = 'value'` and it will be made available as `Rails.configuration.my_config_value`. – Luke Francl Mar 20 '12 at 16:07

score 10 · Answer 3 · answered Sep 06 '18 at 02:14

10

This syntax works for me:

module SetEnvVariable

  def set_env_var(name, value)
   # Old Syntax
   # ENV.stub(:[])
   # ENV.stub(:[]).with(name).and_return(value)

   allow(ENV).to receive(:[]) # stub a default value first if message might be received with other args as well.
   allow(ENV).to receive(:[]).with(name).and_return(value)
  end

end

answered Sep 06 '18 at 02:14

aldrien.h

3,437
2
30
52

1

won't work if you use e.g., `fetch` for `ENV` access. – hoffmanc Feb 04 '19 at 18:39
1

add a couple more lines for fetch: `allow(ENV).to receive(:fetch).with(name).and_return(value)` – Elliott de Launay Dec 01 '21 at 17:25

score 8 · Answer 4 · answered Jun 12 '12 at 01:04

8

As Heroku suggests, you can use Foreman's .env file to store environment variables for development.

If you do that, you can use foreman run to run your specs:

foreman run bundle exec rspec spec

answered Jun 12 '12 at 01:04

ciastek

1,343
12
15

7

It does not help if you want to test outcomes of different values in the same env variable. – Tadas Sasnauskas Jul 20 '15 at 13:41

odlp · Answer 5 · 2021-10-27T16:31:51.573

If you're using dotenv to setup your environment during tests but need to modify an env variable for a specific test then following approach can be useful.

A simpler method than stubbing ENV is to replace the environment for the duration of the test, and then restore it afterwards like so:

with_environment("FOO" => "baz") do
  puts ENV.fetch("FOO")
end

Using a helper like this:

module EnvironmentHelper
  def with_environment(replacement_env)
    original_env = ENV.to_hash
    ENV.update(replacement_env)

    yield
  ensure
    ENV.replace(original_env)
  end
end

By using ensure the original environment is restored even if the test fails.

There's a handy comparison of methods for setting & modifying environment variables during tests including stubbing the ENV, replacing values before / after the test, and gems like ClimateControl.

This is probably the cleanest answer I've seen here. I'd use it with an `around` block for it to be completely idiomatic. — Richard-Degenne, Mar 30 '22 at 16:04

score 4 · Answer 6 · edited Dec 17 '20 at 11:35

4

I'd avoid ENV.stub(:[]) - it does not work if other things are using ENV such as pry(you'll get an error about needing to stub DISABLE_PRY).

#stub_const works well as already pointed out.

edited Dec 17 '20 at 11:35

Viktor

2,623
3
19
28

answered Feb 26 '14 at 22:37

Calvin

1,056
8
5

score 4 · Answer 7 · answered Nov 05 '14 at 22:58

You can use https://github.com/littleowllabs/stub_env to achieve this. It allows you to stub individual environment variables without stubbing all of them as your solution suggested.

Install the gem then write

before :each do
  stub_env('AWS_ACCESS_KEY_ID', 'asdf')
  stub_env('AWS_SECRET_ACCESS_KEY','secret')
end

score 1 · Answer 8 · answered Jun 05 '13 at 05:01

1

What you want is the dotenv gem.

Running tests under foreman, as @ciastek suggests, works great when running specs from CLI. But that doesn't help me run specs with Ruby Test in Sublime Text 2. Dotenv does exactly what you, transparently.

answered Jun 05 '13 at 05:01

Tim Scott

15,106
9
65
79

What is the best way to write specs for code that depends on environment variables?

8 Answers8

Linked