On Tue, Nov 2, 2010 at 10:39 AM, Iain E. Davis <i...@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.a...@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 <dolze...@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 > example/test.
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 allow_mass_assignment_of matcher 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 'declarative' methods. 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. -- Rick DeNatale Help fund my talk at Ruby Conf 2010:http://pledgie.com/campaigns/13677 Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
