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 <[EMAIL PROTECTED]> wrote: > >> David Chelimsky wrote: >> >>> On 10/19/07, Ben Mabey <[EMAIL PROTECTED]> 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("[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 > _______________________________________________ > rspec-users mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
