As to extending the hash instance instead of extending the Hash class within the spec_helper or somewhere with similar effect was I didn’t want to extend all my Hash instances in non test code. I wasn’t planning on adding except/only to the application and extending the Hash class would make the functionality present and potentially used. So I guess I was protecting myself from Ruby’s extensibility by limiting the extension to explicit declarations.

That said on a subsequent rails project I ended up adopting ‘except’ and ‘only’ for the entire application as I wanted to use the extension and ended up extending Hash in the environment.rb.

This is starting to lead me to Ruby Facets which provides numerous useful core extensions.

However, I used an instance class in spec_helper.rb instead of going the module/extend approach, ie:

class Hash

def except(*keys)
self.reject do |k,v|
keys.include? k.to_sym
end
end

def only(*keys)
self.dup.reject do |k,v|
!keys.include? k.to_sym
end
end

end

This way, it’s no longer necessary to extend every hash you want to use these functions on, the functionality is just there.

I’m not criticizing your approach, but I am curious if there was a particular reason you decided to go the route you did with it?

Still even if you were to maintain fixtures for a common development data they need not interfer with using this technique to validate the model’s correct behavior. The fixtures written for model validation will be invalid and wouldn’t be used for a controller specification.

That said when writing controller specs I hardly ever use the actual model to test and keep them as lean as possible. I avoid loading fixtures in the database (due to the performance drag plus after the fact adjustments) whenever possible.

Does the hash way start duplicating fixtures too much? or I miss something?