[rspec-users] View-Driven-Development by Behavior-Driven-Development and RSpec

David Chelimsky dchelimsky at gmail.com
Mon Jul 30 09:31:50 EDT 2007


On 7/30/07, Mikel Lindsaar <raasdnil at gmail.com> wrote:
> > I would tend to disagree. RSpec is a Behaviour Driven Development
> > tool. The idea is that you write a small example of behaviour FIRST,
> > and use that example to drive the implementation. The reason you use
> > examples to drive implementation comes from the idea in Test Driven
> > Development that it will lead to tighter, more focused and more
> > flexible implementations.
> >
> > That all make sense?
>
> Yes, that makes sense.
>
> But I am thinking more of on the side of having the situation where
> you are spec'ing Thing and Thing has to call People or interact with
> people.... tracking those interactions and the interfaces used would
> be something needed...
>
> Because those interfaces are the tool we use to get the behaviour out of People.
>
> In the present (unless I am missing something) the cycle of action
> goes something like:
>
> I spec out the behaviours of a view (say it is the dashboard on 37signals).
>
> This view has a lot of interactions with other Classes.. all over the
> place.  But right _now_ I am doing the view, so I mock out all of the
> other classes and just focus in on the View that I am working on.
>
> Good... all specs pass, the page looks presentable... now what?
>
> Well... go code up the controller responsible for the view.  That's a
> no brainer, for the view's controller....
>
> But then what is the best practice from here for all the other models
> it talks to?
>
> Walk through the view spec line by line finding each mock'd model and
> taking each one and coding the spec and then the code...? (sounds
> awfully unDRY ... as, really, you have already specified a behaviour
> for the model by stubbing or mocking it out....)

That's an interesting perspective, but I'm not sure that I agree with
it. Let's say, for example, that in the view we show one thing if a
model is valid, but another if a model is not valid. Not terribly far
fetched. Have we specified what it means to be valid? Absolutely not!

If anything, what has been specified is a thin picture of an API, just
the method names that should be supported. I don't think that is
behaviour.

>  Surely this is a
> good task for a computer which is good at doing the very repetative
> and manual action of "Go find me all the behaviours specified out for
> this class that other classes need so that they can work".
>
> Assuming you went ahead and cleaned up all those views, what is the
> best way to know you didn't miss a class call?  Or am I really just
> missing the point and all of this is what comes under the umbrella of
> integration testing?

I tend to work in small, complete vertical slices rather than
completing one layer at a time. So rather than doing the whole view
first, I'd do one small aspect of it and then push right down to the
controller action that supports that aspect of it, then push down to
the model, then back up to the next little bit starting from the view.

And yes, this is all much more sane if you're doing integration
testing as well. Automated integration testing, that is - ultimately,
running the app in production IS integration testing - but we'd prefer
to avoid catching the things we missed in that particular framework.

> Having said all of the above, I am finding Rails RSpec has totally
> changed the way I think about coding and designing code... it is
> wonderful...

Glad to hear it.

Cheers,
David

>
> Regards
>
>
> Mikel
>
>
>
> On 7/30/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 7/30/07, Mikel Lindsaar <raasdnil at gmail.com> wrote:
> > > I find myself doing the same thing... the, open the model and type in
> > > the it shoulds...
> > >
> > > I ws thinking along the same line... probably all that would be needed
> > > is a rake task that hooks into the Mock class and runs all the specs
> > > taking not of all the stubs and mocks method calls that are made.
> > >
> > > Then it could PRODUCE the it shoulds...
> > >
> > > @model = mock_model(People, :id => 1, :name => "Bob")
> > > @model.should_receive(:alive?).and_return(true)
> > >
> > > # rake spec:find_fakes
> > >
> > > produces:
> > >
> > > describe People "automatically" do
> > >
> > >   it "should have a name"
> > >
> > >   it "should respond to alive?"
> > >
> > > end
> > >
> > > Now... that would be cool....
> >
> >
> > If your examples come after the code, whether they are generated or
> > you write them yourself, then you are losing out quite a bit of value
> > of the process with which RSpec is aligned.
> >
> > Secondly, having a name is not behaviour. Using it might be. Or how
> > you set it might be. For example:
> >
> > describe Thing do
> >   it "should use the first initializer argument as its name" do
> >     Thing.new("João").name.should == "João"
> >   end
> >
> >   it "should be alive when first created" do
> >     Thing.new.should be_alive
> >   end
> > end
> >
> > Implicit in these examples are the fact that Thing has a name and
> > responds to "alive?", but those are just artifacts in support of the
> > behaviour.
> > _______________________________________________
> > 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
> http://rubyforge.org/mailman/listinfo/rspec-users


More information about the rspec-users mailing list