This is a quick tip where I’ll show you how to stub (sometimes people also refer to it as mock, but I think stub is more technically correct in this case)
Rails.env while writing unit tests for your application.
Why did I have to do this ? Recently while working on an app in a team there was a piece of code that would clear cache on an
if condition which looked like this:
def clear_cache_in_production if Rails.env.production? Rails.cache.clear end end
Now while researching how to test this piece of code/unit (method) I came across mocking and stubbing in Rspec and decided to stub
Rails.env rather than not writing test for this unit at all.
# Stub string_inquirer = ActiveSupport::StringInquirer.new('production') # allow(Class).to receive(:class_method).and_return(return_value) allow(Rails).to receive(:env).and_return(string_inquirer)
If you don’t know about ActiveSupport::StringInquirer, then here are a couple of helpful articles:
https://robots.thoughtbot.com/always-define-respond-to-missing-when-overriding (It is important to understand
respond_to_missing?and this article does the job)
Although note, the
:cache_store used will be that specified in your testing environment’s configuration file rather than the production one since
Rails.env just returns a string that we stubbed to return something else. This won’t affect the actual configuration we’re using.
Hope that helps!