RSpec::StubbedEnv

• ENV stubbing and hiding via shared contexts for more powerful tests
• Now you don't need to add dotenv just for your spec suite
• ENV hiding via hide_env("FOO") was added in v1.0.2

describe "my stubbed test" do
  include_context "with stubbed env"
  include_context "with hidden env"
  context "with FOO=is bar" do
    before do
      stub_env("FOO" => "is bar")
    end
    it "has a value" do
      expect(ENV.fetch("FOO", nil)).to(eq("is bar"))
      expect(ENV.fetch("FOO")).to(eq("is bar"))
      expect(ENV["FOO"]).to(eq("is bar"))
    end
  end
  context "without BAR set" do
    before do
      hide_env("BAR")
    end
    it "is nil" do
      expect(ENV.fetch("BAR", nil)).to(be_nil)
      expect(ENV["BAR"]).to(be_nil)
    end
    it "raises error" do
      expect { ENV.fetch("BAR") }.to(raise_error(KeyNotFound))
    end
  end
end

This gem has no runtime dependencies.

Tokens to Remember
Works with JRuby
Works with Truffle Ruby
Works with MRI Ruby 3
Works with MRI Ruby 2
Source
Documentation
Compliance
Expert 1:1 Support	or
Enterprise Support	💡Subscribe for support guarantees covering all FLOSS dependencies! 💡Tidelift is part of Sonar! 💡Tidelift pays maintainers to maintain the software you depend on! 📊@Pointy Haired Boss: An enterprise support subscription is "never gonna let you down", and supports open source maintainers!
Comrade BDFL 🎖️
... 💖	🧊 🐙 🛖 🧪

Install the gem and add to the application's Gemfile by executing:

$ bundle add rspec-stubbed_env

If bundler is not being used to manage dependencies, install the gem by executing:

$ gem install rspec-stubbed_env

rspec-stubbed_env is cryptographically signed, and has verifiable SHA-256 and SHA-512 checksums by stone_checksums. Be sure the gem you install hasn’t been tampered with by following the instructions below.

Add my public key (if you haven’t already, expires 2045-04-29) as a trusted certificate:

gem cert --add <(curl -Ls https://raw.github.com/oauth-xx/rspec-stubbed_env/main/certs/pboling.pem)

You only need to do that once. Then proceed to install with:

gem install rspec-stubbed_env -P HighSecurity

The HighSecurity trust profile will verify signed gems, and not allow the installation of unsigned dependencies.

If you want to up your security game full-time:

bundle config set --global trust-policy MediumSecurity

MediumSecurity instead of HighSecurity is necessary if not all the gems you use are signed.

NOTE: Be prepared to track down certs for signed gems and add them the same way you added mine.

You must configure RSpec to use the :expect syntax, or some compatible alternative.

RSpec.configure do |config|
  config.expect_with(:rspec) do |c|
    c.syntax = :expect
  end
end

Require the library in your spec/test helper somewhere:

require "rspec/stubbed_env"

• is opt-in, via a shared context, rather than global.
• does not affect the real ENV at all. It is a true stub.
• has the same scope as a before, subject, or let at the same level.

See the spec suite for detailed examples.

# This is normal, without stubbing, ENV is not set
describe "vanilla" do
  it "has no ENV stub" do
    expect(ENV.fetch("FOO", nil)).to(be_nil)
    expect(ENV["FOO"]).to(be_nil)
  end
end

# With a stubbed ENV!
describe "my stubbed test" do
  include_context "with stubbed env"
  before do
    stub_env("FOO" => "is bar")
  end
  it "has a value" do
    expect(ENV.fetch("FOO", nil)).to(eq("is bar"))
    expect(ENV["FOO"]).to(eq("is bar"))
  end
end

ENV can be stubbed trough the stub_env method, or key/value pairs to be stubbed can be provided directly to the include_context call:

describe "my stubbed test" do
  include_context "with stubbed env", "FOO" => "is bar"

  it "has a value" do
    expect(ENV.fetch("FOO", nil)).to(eq("is bar"))
    expect(ENV["FOO"]).to(eq("is bar"))
  end
end

If you want to make stub_env method available globally (without the include_context call), you can add in the spec_helper.

I do not recommend the global approach, as it results in a loss of clarity on which tests are testing ENV-based behaviors. Here's a foot-gun if you want it.

RSpec.configure do |config|
  config.include(RSpec::StubbedEnv::StubHelpers)
  # Or you could include the context globally
  # config.include_context "with stubbed env"
end

• is opt-in, via a shared context, rather than global.
• does not affect the real ENV at all. It is a true stub.
• has the same scope as a before, subject, or let at the same level.

See the spec suite for detailed examples.

# This is normal, without hiding, ENV is set
ENV["MY_PATH"] = "/home/doodle"
describe "vanilla" do
  it "has ENV with nothing hidden" do
    expect(ENV.fetch("MY_PATH", nil)).to("/home/doodle")
    expect(ENV["MY_PATH"]).to("/home/doodle")
  end
end

# With a hidden ENV variable!
describe "my hidden test" do
  include_context "with hidden env"
  before do
    hide_env("MY_PATH")
  end
  it "MY_PATH is not set" do
    expect(ENV.fetch("MY_PATH", nil)).to(be_nil)
    expect(ENV["MY_PATH"]).to(be_nil)
  end
end

ENV variables can be hidden trough the hide_env method, or variable names to be hidden can be provided directly to the include_context call:

describe "my hidden test" do
  include_context "with hidden env", "MY_PATH"

  it "MY_PATH is not set" do
    expect(ENV.fetch("MY_PATH", nil)).to(be_nil)
    expect(ENV["MY_PATH"]).to(be_nil)
  end
end

If you want to make hide_env method available globally (without the include_context call), you can add in the spec_helper:

I do not recommend the global approach, as it results in a loss of clarity on which tests are testing ENV-based behaviors. Here's a foot-gun if you want it.

RSpec.configure do |config|
  config.include(RSpec::StubbedEnv::HideHelpers)
  # Or you could include the context globally
  # config.include_context "with hidden env"
end

We migrated from master to main as the default branch. If this affected your local checkout:

git branch -m master main
git fetch origin
git branch -u origin/main main
git remote set-head origin -a

See CONTRIBUTING.md.

See SECURITY.md.

If you need some ideas of where to help, you could work on adding more code coverage, or if it is already 💯 (see below) check TODOs (see below), or check issues, or PRs, or use the gem and think about how it could be better.

We so if you make changes, remember to update it.

See CONTRIBUTING.md for more detailed instructions.

Everyone interacting in this project's codebases, issue trackers, chat rooms and mailing lists is expected to follow the .

Made with contributors-img.

Also see GitLab Contributors: https://gitlab.com/pboling/rspec-stubbed_env/-/graphs/main

This Library adheres to . Violations of this scheme should be reported as bugs. Specifically, if a minor or patch version is released that breaks backward compatibility, a new version should be immediately released that restores compatibility. Breaking changes to the public API will only be introduced with new major versions.

Yes. But I'm obligated to include notes...

SemVer should, but doesn't explicitly, say that dropping support for specific Platforms is a breaking change to an API. It is obvious to many, but not all, and since the spec is silent, the bike shedding is endless.

dropping support for a platform is both obviously and objectively a breaking change

• Jordan Harband (@ljharb, maintainer of SemVer) in SemVer issue 716

To get a better understanding of how SemVer is intended to work over a project's lifetime, read this article from the creator of SemVer:

• "Major Version Numbers are Not Sacred"

As a result of this policy, and the interpretive lens used by the maintainer, you can (and should) specify a dependency on these libraries using the Pessimistic Version Constraint with two digits of precision.

For example:

spec.add_dependency("rspec-stubbed_env", "~> 1.0")

See CHANGELOG.md for list of releases.

The gem is available as open source under the terms of the MIT License . See LICENSE.txt for the official Copyright Notice.

Copyright (c) 2018 - 2020, 2024 - 2025 Peter H. Boling, RailsBling.com

You made it to the bottom of the page, so perhaps you'll indulge me for another 20 seconds. I maintain many dozens of gems, including this one, because I want Ruby to be a great place for people to solve problems, big and small. Please consider supporting my efforts via the giant yellow link below, or one of the others at the head of this README.