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
> ;)
>
> -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
