[rspec-users] Patch idea for rspec_on_rails

Ben Mabey
2007-10-19T21:35:24Z

Thanks for the response.  I understand your reasoning, especially about
the whole BDD approach being an unproven/agreed on.
And yes, you have made it really easy to make and distribute custom
matchers.  So thank you!  I''ll keep these extra matchers as a plugin
for
now.

-Ben


David Chelimsky wrote:
> On 10/19/07, Ben Mabey <ben at benmabey.com> wrote:
>
>> David Chelimsky wrote:
>>
>>> On 10/19/07, Ben Mabey <ben at benmabey.com> wrote:
>>>
>>>
>>>> I would think that something like this should be worked into
>>>> rpsec_on_rails.  Because it makes testing AR behavior very easy
and
>>>> painless.  One line of code = One line of test code.
>>>>
>>>>
>>> I''d be hesitant to include it in rspec_on_rails. I
don''t really see
>>> this as testing AR *behaviour* at all. It''s pure
structure. To me this
>>> is no different than specifying that a Group should have an Array
of
>>> Users. And the reason we don''t want to specify that is
that if we
>>> decide to change the Array to a Hash internally, without affecting
>>> Group''s methods, then we''d have to change the
specs.
>>>
>>> But I''d encourage you to publish this as a gem or plugin.
I''m sure a
>>> lot of people would like to use it, in spite of my opinions.
>>>
>
> <snip>
>
>
>> Ok, well, when I said it tests AR behavior I referring to the other AR
>> matchers and not the association matchers that we are talking about.
>> Sorry for the confusion. This is a better example of what I mean:
>> http://pastie.caboo.se/109016
>>
>> In this pastie we are actually testing the behavior for
>> validate_presence_for, would you agree?
>>
>
> I do agree that what''s inside the matcher looks right, but the
fact
> that you invoke it with validates_presence_of is a bit misleading in
> that case. If I don''t look at the implementation of the matcher, I
> would assume that it validates the declaration. So, perhaps, this
> would be closer to the mark with different words like require:
>
> @user.should require(:email).with_warning_message("can''t be
blank")
>
> or something like that. I''ve actually got the following in one of
my projects:
>
> @user.should reject(nil).for(:email)
> @user.should reject("this is not an email").for(:email)
> @user.should accept("this.might.be.an at email.com").for(:email)
>
> I kind of like that too.
>
>
>>  I can understand your
>> hesitation about the association matchers but do you have similar
>> reservations about having matchers that test the behavior of rails
>> validations?
>>
>
> I do have less reservation about that, yes. However, there are a
> number of solutions that people have come up with and until I have
> time to look at a bunch of them and use them myself to get a sense of
> how they feel in process, I''m probably not going to add them.
>
> Why not just publish it yourself?
>
>
>> I know that this topic comes up on the list at least every other week.
>> And it is the same argument time after time:  You can mock the class
out
>> and make sure it receives the the validation call.. but doing it that
>> way does not actually test the behavior... well it isn''t our
code so we
>> shouldn''t be testing it... but it is an important part of that
model''s
>> behaviour that needs a spec for... etc...  Would including default
>> validation matchers in rails_on_rspec be a bad thing just because of
the
>> difference of opinions on it?
>>
>
> Yes it would absolutely be a bad thing. Until we decide what is the
> right approach from a BDD perspective, it is completely inappropriate
> for rspec to be endorsing any one approach.
>
> On the flip side, as I said above, there''s nothing stopping you
and
> Russell from publishing your libraries as gems or plugins. Let people
> try them out. That''s part of the reason we made matchers so
cleanly
> decoupled from the rest of rspec - anybody can publish libraries and
> just plug them right in.
>
> I appreciate your desire to share w/ the group, and that is a good way
> to do it. I hope you understand my reasoning for not wanting to add
> something like this, at least for the time being.
>
> Cheers,
> David