[rspec-users] Patch idea for rspec_on_rails
ben at benmabey.com
Fri Oct 19 17:35:24 EDT 2007
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
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.
>> 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:
>> 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
> 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.
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users