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

David Chelimsky dchelimsky at gmail.com
Mon Jul 30 08:36:00 EDT 2007


On 7/30/07, Daniel N <has.sox at gmail.com> wrote:
> On 7/30/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 7/30/07, Daniel N <has.sox at gmail.com> wrote:
> > > 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....
> > > >
> > > > 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.
> > > >
> > > > 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.
> > > >
> > > > That all make sense?
> > >
> > > In a fairly abstract way.  But how do you keep track of what methods
> have
> > > been stubbed or mocked?
> > >
> > > From the above Thing.new.alive?  will need to be defined.  This seems to
> be
> > > the spec for Thing, but if in a view I said
> > >
> > > it "should do_stuff if @thing is alive" do
> > >
> > >   @thing = mock_model( Thing )
> > >   @thing.stub!( :alive? ).and_return( true )
> > >   controller.should_receive( :do_stuff )
> > >   do_get
> > >
> > > end
> > >
> > > How do I run the view first without Thing,
> >
> > If you're using mock_model and the constant Thing, then you have to
> > create Thing to get that example to run. Admittedly, having to create
> > that model class is a distraction from the flow, but it is a very
> > small distraction that has never really bothered me that much. I
> > imagine that we could tweak mock_model to accept a String, or perhaps
> > somebody with stronger TextMate chops than mine could submit a patch
> > to the TextMate bundle that would let you click on Thing and create a
> > Thing model.
> >
> > > and also keep track of alive?
> > > being decalred on the Thing instance?
> >
> > This is something that has come up on this list and in RFEs a few
> > times. The most promising idea is to have a command line switch that
> > would look at any mock that was passed a class name and ensure that
> > the class responds to any mocked or stubbed methods. But even that
> > would fall apart as soon as you start using any metaprogramming
> > techniques to change the nature of an object at runtime.
>
>
> David,
>
> Is it not possible to check if a mocked model actually responds to a method
> call at the point of it being called?
>
> Then capture any that aren't on the original object and print out warnings
> similar to the pending notices?
>
> Please excuse my ignorance.  I'm sure I've oversimplified this dramatically.

Actually, that doesn't sound ignorant at all. I was thinking about it
differently.

Wanna take a crack at a patch? Here's the relevant RFE:

http://rubyforge.org/tracker/index.php?func=detail&aid=5064&group_id=797&atid=3152

> ;)
>
>  -Daniel
>
> > For me, the answer to keeping track of mocked methods is automated
> > end-to-end tests. Either in browser, or something like Rails'
> > integration tests (assuming Rails), or (soon) rbehave's story runner
> > (which is now being integrated into rspec).
> >
> > Cheers,
> > David
> >
> >
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


More information about the rspec-users mailing list