But dont you really just want to test the behavior of the class?
(whereas the validator call is an implementation)
such as
it "should require digits" do
p = PhoneNumber.new( :digits => nil )
p.should_not be_valid
p.errors.on(:digits).should == "can't be blank"
end
On Oct 19, 2007, at 9:25 AM, Daniel Tenner wrote:
> Hi all,
>
> I've been thinking about the whole validator/relationship speccing
> issue, and I came up with a suggestion, which I'd love to get some
> feedback on.
>
> The full article is available at http://www.inter-sections.net/
> 2007/10/19/what-to-test-and-specify-and-where-to-do-it/ , with the
> relevant bit being about halfway down, but here's the gist of it:
>
> 1. "@user.new(some attr) .. @user.should_be valid" is not behaviour
> specification, it's outcome specification, and as such should not be
> in any spec. It also happens to be testing someone else's code (the
> rails validation code), which shouldn't need to be specified since we
> didn't write it.
>
> 2. The reason why people (myself included) feel compelled to include
> stuff like that is, in great part, because it helps codify our
> assumptions about the way ActiveRecord (or any other external
> components) work, which are sometimes not clear (as with non-trivial
> validations) and liable to change as Rails evolves.
>
> Therefore, these are a new kind of beast - not a system integration
> test (not system-wide or anything to do with users), not a behaviour
> specification (not specifying our own code, outcome driven) - but
> instead what I'm currently calling an "assumption test".
>
> I feel that these should be formalised, because writing somethiing
> like:
>
> it “should validate_presence_of digits“ do
> PhoneNumber.expects(:validates_presence_of).with(:digits)
> load “#{RAILS_ROOT}/app/models/phone_number.rb“
> end
>
> is only meaningful as a specification if you assume that
> "validates_presence of :digits" is the right syntax to use. So
> therefore, it is based on an assumption about ActiveRecord, that
> should be explicitly tested for at the unit level, so that if Rails
> behaves in a different way, you'll know about it at the unit level.
>
> So my suggestion would be that we create an "assumptions" folder
> somewhere in the rails folder hierarchy, so that we have 3 beasts:
> assumptions, specs, and stories.
>
> Obviously this could have dire consequences that I haven't thought
> of, hence why I'd like to hear what other people's opinions are about
> this. I've discussed some aspects of this briefly on #rspec with
> David (chelimsky) (I'm swombat), but would love more opinions about
> it, and it seems that all the fun stuff happens on the mailing
> list :-)
>
> Thanks for any feedback,
>
> Daniel
> http://www.inter-sections.net/
> (swombat on freenode#rspec)
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
