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

Daniel N has.sox at gmail.com
Mon Jul 30 08:40:16 EDT 2007


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, 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



Sure I'll try.  I am not at all familiar with Rspec internals though.


> ;)
> >
> >  -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
> >
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070730/c9666979/attachment.html 


More information about the rspec-users mailing list