[rspec-users] a better "should have valid associations"
dchelimsky at gmail.com
Sat Mar 31 16:44:13 EDT 2007
On 3/31/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 3/31/07, Dave Astels <dastels at daveastels.com> wrote:
> > I'll play devils-advocate.. what does all this have to do with specifying
> > behaviour?
> Probably not much, but can't we say that about most of RSpec's
> built-in matchers? Like for example:
> foo.should match(/bar/)
> What does that have to do with behaviour?
I think it gets too easy to say "if we're checking state it's not
about behaviour" but I think that's wrong. Some objects answer
questions - and that IS their behaviour. If an object answers the same
question in two different ways based on what you've done (or not done)
before you ask the question, then that is behaviour.
I think the distinction here is that we're really describing an
object's structure, not its behaviour, when we say:
This is an interesting dilemma that were forced to negotiate our way
through because Rails breaks what have long been considered good
Object Oriented principles like "favor delegation over inheritance".
It is adherence to that principle, in my view, that makes Spring the
hands down winner over Struts in the java space. Well, there are other
reasons as well.
But there's a counter argument to all this, which is pragmatism. I can
express a lot of implied behaviour by saying:
describe User do
it "should require email" do
I think that has some value.
The risk, of course, is that we're now married to Rails and it would
be hard to use a different framework without changing all of our
examples. If that's the fear, then you really shouldn't be using
Rails to begin with.
> > From a specification point of view, do I care that there's a valiadtor for a
> > field? I don't think so... I'm more concerned with what happens when I try
> > to use a bad value for that field. That there's a validator for it in the
> > model is an implementation detail.
> > That said, it's great stuff for a plugin.
> I've been thinking - would it make sense to modify the rspec_resource
> generator to generate specs that use the matchers provided by Josh's
> plugin? It would be possible to infer from foreign key fields passed
> as arguments to the generator (name:string project_id:integer) etc.
My instinct is that I wouldn't want the dependency from Spec::Rails to
another plugin. If that's the goal we should either ship the
rspec_resource generator as a separate plugin or move Josh's plugin
into RSpec (w/ his permission, of course).
Thoughts on that (especially from Josh)?
> > Dave
> > _______________________________________________
> > 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
More information about the rspec-users