On 7/30/07, Daniel N <[EMAIL PROTECTED]> wrote:
> On 7/30/07, David Chelimsky <[EMAIL PROTECTED]> wrote:
> > On 7/30/07, Daniel N <[EMAIL PROTECTED]> wrote:
> > > On 7/30/07, David Chelimsky <[EMAIL PROTECTED]> wrote:
> > > > On 7/30/07, Daniel N < [EMAIL PROTECTED]> wrote:
> > > > > On 7/30/07, David Chelimsky <[EMAIL PROTECTED]> wrote:
> > > > > > On 7/30/07, Mikel Lindsaar < [EMAIL PROTECTED]> 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.
This is specific to the mocking framework, and should work for any
application (rails or not), so you should be able to just focus on
that part of the system.
>
> > > ;)
> > >
> > > -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@rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-users
> > >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users@rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
