On Thu, Feb 12, 2009 at 11:59 AM, David Chelimsky <dchelim...@gmail.com> wrote: > On Feb 12, 2009, at 1:03 PM, Nick Hoffman <n...@deadorange.com> wrote: > >> Does RSpec automatically call #valid? on ActiveRecord models? >> >> For instance, when this example is run: >> >> it 'should reject a nil value' do >> @form = TimeShiftForm.new :file => nil >> >> puts "@form.errors.count = <<#...@form.errors.count}>>" >> @form.should have(1).error_on :file > > This matcher, have(1).error_on, does call #valid. > >> >> puts "@form.errors.count = <<#...@form.errors.count}>>" >> end >> >> This is printed: >> @form.errors.count = <<0>> >> @form.errors.count = <<1>> >> >> However, I never called @form.valid? , which leads me to believe that >> RSpec called it for me. > > In this case, yes, because the matcher needs that. > >> If RSpec does in fact call #valid? automatically, should we refrain from >> manually calling #valid? > > The fact that you are asking this shows that we're violating the principle > of least surprise. We could make it so it doesn't validate, but that would > pit the onus on users to validate explicitly (not to mention the upgrade > burden). > > Thoughts?
Yes it's a surprise, but maybe a pleasant one? I actually didn't know about this until 2 weeks ago :) One of my coworkers showed me a spec that included error_on but didn't explicitly call valid? We both scratched our heads a bit, prompting me to check out the code. I think it'll catch a few people by surprise. I don't know that it will lead to errors though. And I think it keeps the code a bit cleaner (valid? may be explicit, but it's noisy as well), still expressing the intent well. Pat _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
