Close
Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

LABS
Redefining Constants

This post was originally written by Brian Takita.

We all like a good oxymoron, like redefining constants. There are times where we need to redefine a constant to test an edge case in the application code. Before I go into this example, please note that redefining constants is generally not a good way to have maintainable software. If you find yourself needing to redefine a constant, it may be an indication that refactoring is needed.

Given that, lets get into an example where you may need to redefine a constant. Lets say an app has does file uploads to Amazon’s S3 service. A common practice to upload to a real S3 account made for the production, development, or demo environment.

When in the test environment, a fake S3 service would be used instead. The fake service is useful to keep your tests fast and running predictably.

To get a different File Upload service object in each of your environments, one can have the S3 configuration in the environment files:

test.rb

STORAGE_SERVICE = FakeStorageService.new

development.rb

STORAGE_SERVICE = S3StorageService.new("development_service", "access_key", "secret_access_key")

production.rb

STORAGE_SERVICE = S3StorageService.new("production_service", "access_key", "secret_access_key")

The File Upload service objects can be set to constants in the environment file. This works great when testing the logic of the objects that use the File Upload service. However it is a good idea to run an integration test that does a real upload.

Since the tests are running in the test environment, a fake File Upload service is being used. Well now we want to use a real service that points to a test S3 account. An easy trick is to redefine the constant to the S3 service in setup and then redefine the constant back to the fake service on teardown.

There are a few ways of doing this…

Just Reset the Constant

context "A real S3 call" do

  setup do

    STORAGE_SERVICE = S3StorageService.new("test_service", "access_key", "secret_access_key")

  end

  teardown do

    STORAGE_SERVICE = FakeStorageService.new

  end

end

This is the simplest approach, but it produces an error:

warning: already initialized constant STORAGE_SERVICE

###Use silence_warnings

context "A real S3 call" do

  setup do

    silence_warnings do

      STORAGE_SERVICE = S3StorageService.new("test_service", "access_key", "secret_access_key")

    end

  end

  teardown do

    silence_warnings do

      STORAGE_SERVICE = FakeStorageService.new

    end

  end

end

This solution removes the warning, but now a certain section of your code will not have warning at all. Also, one could argue that you lose semantic meaning. It also feels like a hack.

Redefine the Constant

class Module

  def redefine_const(name, value)

    __send__(:remove_const, name) if const_defined?(name)

    const_set(name, value)

  end

end



context "A real S3 call" do

  setup do

    Object.redefine_const(

      :STORAGE_SERVICE,

      S3StorageService.new("test_service", "access_key", "secret_access_key")

    )

  end

  teardown do

    Object.redefine_const(

      :STORAGE_SERVICE,

      STORAGE_SERVICE = FakeStorageService.new

    )

  end

end

Calling redefining the constant does not generate a warning. Also it does provide semantic value because you are actively declaring that you are redefining the constant. If there are other warnings, you will also see them.

Its all Dirty

Redefining constants is a non-standard tatic, especially for those new to Ruby. Since this is unconventional and is often contrary to assumptions, it may lead to unpredictable behavior.

Maybe the storage service can be an attribute that can be changed for individual tests.

Comments
  1. Chad Woolley says:

    Here’s a couple of more recent, Ruby-specific resources on Dependency Injection:

  2. Brian Takita says:

    A configuration object makes more sense, especially the example this article used.

    Sometimes, this isn’t an available option though.
    If you are able to refactor to a configuration object, do it.

  3. Chad Woolley says:

    I wrote a post on an alternative approach that avoids the need to redefine constants:

    http://www.pivotalblabs.com/articles/2007/04/16/avoiding-constants-in-rails

    Can you think of any situations when this approach would not be an available option?

  4. Brian Takita says:

    Having to live with constants rears itself mainly in code you can’t control.

    For example, there is RAILSENV and RAILSROOT and third party code that uses these constants directly. While it is an option to refactor the third-party code, there is overhead in maintaining a branch. The best option in this case would be to submit a patch that creates an accessor for railsenv and railsroot to the project. It can be initialized or lazily defaulted to their respective constants.

    There are a number of techniques to simulate different values for RAILS_ENV.

    • Redefine the constant
    • Set a RAILS_ENV constant in the class you are trying to test
    • RAILS_ENV.replace

    None of these techniques are nearly as appealing as setting a hash or writer method though.

    I can’t think of any other good reasons…

  5. p says:

    Thanks for the helpful post and discussion!

    Here is an example where this technique of redefining a constant is useful, where a configuration object approach can’t help:

    Change the ActionController::Routing::Segment’s RESERVED_PCHAR, SAFE_PCHAR and UNSAFE_PCHAR constant definitions: Either because one is using an earlier RoR where this patch is unavailable: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/2574-routing-double-escape-url-segments or modifying them to include/exclude a few other characters for the particular app need.

    Cheers,
    Philip

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *