[rspec-users] Assumption tests

David Chelimsky dchelimsky at gmail.com
Fri Oct 19 10:45:15 EDT 2007


On 10/19/07, Jonathan Linowes <jonathan at parkerhill.com> wrote:
> But dont you really just want to test the behavior of the class?

The object, not 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

If I read correctly, Daniel is suggesting that this is not behaviour
because he's equating behaviour with interaction. This example checks
an outcome, not an interaction.

Personally, I don't draw boundaries around what is behaviour at
interaction. For me it's what does it look like from the outside as
opposed to what it looks like on the inside. State testing is
perfectly fine, as long as you're testing externally observable state
as opposed to internal state. For example, imagine that p.valid?
relies on an internal flag named @valid. Doing this would be fine:

  p.should be_valid

But doing this would be evil:

  p.instance_eval { @valid }.should be_true

The idea is to decouple specs from the things that change so they are
less brittle. Internal structure tends to change more than an object's
API. Make sense?

So with that, I really don't think there is a need for a new grouping
of tests. That's my opinion. I look forward to everyone else's.

Cheers,
David

>
>
> 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 at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


More information about the rspec-users mailing list