On 10/19/07, Ben M. [email protected] wrote:
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:
Parked at Loopia
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(“[email protected]”).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
