[rspec-users] Testing attr_accessible (and/or attr_protected)
rick.denatale at gmail.com
Tue Nov 2 11:31:32 EDT 2010
On Tue, Nov 2, 2010 at 10:39 AM, Iain E. Davis
<iain at somethingelectronic.com> wrote:
> I failed to mention I'm using Rails 2.3.8 and Rspec-1.3.x. I should
> have said that right away.
> On Tue, Nov 2, 2010 at 01:33, Alexey Ilyichev <bluesman.alex at gmail.com> wrote:
>> An attempt to assign protected attributes leads to the warning in your log
> Hmm... Maybe I should actually look at the log once in a while...
>> article.update_attributes(:person_id => @person.id)
>> article.person_id.should == nil # or whatever it is before update call
> On Tue, Nov 2, 2010 at 02:13, Evgeniy Dolzhenko <dolzenko at gmail.com> wrote:
>> 1. perform update_attributes for an attribute and then assert that the attribute didn't change
> Buh. I wish I had thought of that. Seems rather obvious now...I
> confess I was expecting something esoteric and thus didn't stop to
> think if there was a simple solution. :)
> To me, checking whether the attribute changed is more straight-forward
> than implementing a custom matcher, at least at my current level of
> experience (novice) with rails and rspec.
> I suppose I need to be careful that the attribute change was rejected
> for some other reason (bad data, for example). But that's true of any
Note that Evgeniy's two suggestions:
1. perform update_attributes for an attribute and then assert that the
attribute didn't change
2. go a bit "meta" and implement something like Shoulda
Represent two different philosophies.
The first, feels to me more like you are specifying/testing the
behavior of ActiveRecord rather than your own code. It indirectly
tests whether or not attr_accessible/attr_protected is in effect by
observing the effect on one of the methods which are effected by those
In general I prefer to concentrate on specifying/testing the code I
write. The second approach is more compatible with that philosophy.
I trust that ActiveRecord correctly implements protected attributes,
what I want to prove is that my code is using them.
This is independent of whether or not a custom matcher is used. For
example Wincent's implementation of the matcher takes the first
approach, while the shoulda macro instead examines whether or not the
model has an attribute set as accessible directly.
Now the shoulda approach is dependent a bit on the implementation in
activerecord, which is a reason to look for such plugins before trying
to write them yourself, an open-source plugin has more eyes on it and
will probably adapt to any changes before you run into them yourself.
And as Wincent points out, you don't usually need to do such plumbing
yourself, there are lots of RSpec compatible matchers (including the
Shoulda matchers) freely available.
Help fund my talk at Ruby Conf 2010:http://pledgie.com/campaigns/13677
More information about the rspec-users