Run your specs and features in different environments

By default your specs and cucumber feature both run in the test rails environemnt i.e. RAILS_ENV=test.

However, I need these two environments to be different. First I’ll show you how, then I’ll tell you why.

I want to have my feature run in a cucumber environment i.e. RAILS_ENV=cucumber. Simply edit the features/support/env.rb file and update the default environment value so that you file looks like this:

ENV['RAILS_ENV'] = 'cucumber'
Rails.env = 'cucumber'

We still want our feature to hit the test database, so simply create a pointer in your database.yml file to do this:

test: &TEST
  adapter: ...
  database: ....
  host: ...

  <<: *TEST

Lastly, make sure you have a config/environments/cucumber.rb file for your new cucumber environment. I normally just copy the test environment file.

Now when you run your features they will run in their own, separate environment. Groovy.

Optional: You may also want to modify your Gemfile by adding an additional :cucumber group. I’ve never done this and never run into any problems, but bear it in mind.

Why do I need this?

When I run my specs I use spork and autotest. This makes running specs lightning fast. However, you do need to make some tweaks to the test.rb environment file, namely turning class caching off. This is to make sure your specs always run with the latest saved versions of your models.

config.cache_classes = false

For cucumber, you can leave caching on. However, I use database_cleaner for my features with a truncation strategy. This makes the running of selenium features reliable because no transaction has to be rolled back after each scenario – the data is simply truncated.



7 thoughts on “Run your specs and features in different environments

  1. Thanks for this quick rundown for creating a new environment. I’ve got this working, but when I run a feature with @javascript it looks like selenium is running the browser in my development environment. Any idea how to resolve this?

  2. Strange. I’ve checked 3 of my apps in which I do this and they all behave as expected: feature run in the CUCUMBER environment. The only thing I can advise is to double check your setup is correct, making sure your database.yml file is correct too.

  3. One other important tip for many people will be to modify their Gemfile. If they’ve got the typical :test and :development group defined, they’ll need to a :cucumber to that group.

    1. True, although this is not necessary. I suppose it depends on how many gems you are using and whether it makes sense to have separate groups for :test and :cucumber. I’ve never felt any need for this as if I’m running tests I want to run ALL my tests, not just the cucumbers or specs. Either way, it will work.
      Post updated accordingly though, thanks.

  4. Alternatively … i found you could still use the test environment but set a constant in your features/support/env.rb such as

    CACHE_CLASSES = true

    Then in config/environments/test.rb you can check for this constant, setting it to false (for rspec/spork) if not otherwise set.

    CACHE_CLASSES ||= false
    config.cache_classes = CACHE_CLASSES

    1. Another good point, but again it depends entirely on your application and what you need to do differently across the :test and :cucumber environments. I typically use database transactions for running specs. For cucumber, I typically use a DatabaseCleaner.strategy of :truncation and also use webmock to stub external API calls, so I like to split the two environments.

      Thanks for the tip though.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s