Unwanted symbol to string conversion of hash key

问题

When I assign in my controller

@my_hash = { :my_key => :my_value }

and test that controller by doing

get 'index'
assigns(:my_hash).should == { :my_key => :my_value }

then I get the following error message:

expected: {:my_key=>:my_value},
got: {"my_key"=>:my_value} (using ==)

Why does this automatic symbol to string conversion happen? Why does it affect the key of the hash?

回答1:

It may end up as a HashWithIndifferentAccess if Rails somehow gets ahold of it, and that uses string keys internally. You might want to verify the class is the same:

assert_equal Hash, assigns(:my_hash).class

Parameters are always processed as the indifferent access kind of hash so you can retrieve using either string or symbol. If you're assigning this to your params hash on the get or post call, or you might be getting converted.

Another thing you can do is freeze it and see if anyone attempts to modify it because that should throw an exception:

@my_hash = { :my_key => :my_value }.freeze

回答2:

You might try calling "stringify_keys":

assigns(:my_hash).should == { :my_key => :my_value }.stringify_keys

回答3:

AHA! This is happening not because of Rails, per se, but because of Rspec.

I had the same problem testing the value of a Hashie::Mash in a controller spec (but it applies to anything that quacks like a Hash)

Specifically, in a controller spec, when you call assigns to access the instance variables set in the controller action, it's not returning exactly the instance variable you set, but rather, a copy of the variable that Rspec stores as a member of a HashWithIndifferentAccess (containing all the assigned instance variables). Unfortunately, when you stick a Hash (or anything that inherits from Hash) into a HashWithIndifferentAccess, it is automatically converted to an instance of that same, oh-so-convenient but not-quite-accurate class :)

The easiest work-around is to avoid the conversion by accessing the variable directly, before it's converted "for your convenience", using: controller.view_assigns['variable_name'] (note: the key here must be a string, not a symbol)

So the test in the original post should pass if it were changed to:

get 'index'
controller.view_assigns['my_hash'].should == { :my_key => :my_value }

(of course, .should is no longer supported in new versions of RSpec, but just for comparison I kept it the same)

See this article for further explanation: http://ryanogles.by/rails/hashie/rspec/testing/2012/12/26/rails-controller-specs-dont-always-play-nice-with-hashie.html

回答4:

I know this is old, but if you are upgrading from Rails-3 to 4, your controller tests may still have places where Hash with symbol keys was used but compared with the stringified version, just to prevent the wrong expectation.

Rails-4 has fixed this issue: https://github.com/rails/rails/pull/5082 . I suggest updating your tests to have expectations against the actual keys.

In Rails-3 the assigns method converts your @my_hash to HashWithIndifferentAccess that stringifies all the keys -

def assigns(key = nil)
  assigns = @controller.view_assigns.with_indifferent_access
  key.nil? ? assigns : assigns[key]
end

https://github.com/rails/rails/blob/3-2-stable/actionpack/lib/action_dispatch/testing/test_process.rb#L7-L10

Rails-4 updated it to return the original keys -

def assigns(key = nil)
  assigns = {}.with_indifferent_access
  @controller.view_assigns.each { |k, v| assigns.regular_writer(k, v) }
  key.nil? ? assigns : assigns[key]
end

https://github.com/rails/rails/blob/4-0-stable/actionpack/lib/action_dispatch/testing/test_process.rb#L7-L11

回答5:

You can also pass your Hash object to the initializer of HashWithIndifferentAccess.

回答6:

You can use HashWithIndifferentAccess.new as Hash init:

Thor::CoreExt::HashWithIndifferentAccess.new( to: 'mail@somehost.com', from: 'from@host.com')

来源：https://stackoverflow.com/questions/4348195/unwanted-symbol-to-string-conversion-of-hash-key