[rspec-users] Assumption tests

Daniel Tenner daniel.ruby at tenner.org
Fri Oct 19 11:26:36 EDT 2007


> 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.
>

That's right, one of my axioms is that "specifying" involves  
behaviour/interaction, not state/outcome.

The reason for this is that I believe that this is the only way to  
gain the full benefit from the fact that behaviours can be laid on  
top of each other without interfering with each other (the benefit  
being robustness of the specifications). This is all explained in  
another post on my blog, but I'm not trying to advertise it, only to  
have a discussion :-)

Daniel

On 19 Oct 2007, at 15:45 19 Oct 2007, David Chelimsky wrote:

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



More information about the rspec-users mailing list