rspec users - Jul 2007 - View-Driven-Development by Behavior-Driven-Development and RSpec

One of the things that turned me on to BDD and RSpec was speccing  
views first, that the desired end would drive the development.  In  
previous projects while using Test::Unit I would try to make educated  
guesses as to what would be needed in the model and controllers to  
derive the view without actually writing the view until afterwards.  
This is all because testing relied on each previous layer working for  
the next to work, first models, then controllers, then views.  And  
while for the most part the educated guesses panned out, and I''d do  
the models/controllers/views incrementally, I''d repeat a specific  
process a lot.

Test/write model(s)
Test/write controller(s)
Test/write view(s)...oops, I forgot something or I need some extra  
functionality out of the model (or controller) which I didn''t guess  
the view would need.

Lets go back to the model to test/add the functionality
Lets test/add functionality in the controller to include this
Lets test the functionality in the view that we had to go back and  
write support code for (if you even do this with Test::Unit, flooding  
your functional tests with ugly ugly ugly tests)

Rinse and repeat, quickly trying to switch contexts from models to  
controllers to views.  While testing helps you predict failures when  
making changes, it''s not perfect, and predicting problems in the  
views is even more difficult with the current state of view testing  
in Test::Unit.

While it is still rather agile, and changing the contexts isn''t  
really much of a switch in this case, I think a lot could be avoided  
by doing views first and letting it drive the controllers and  
models.  Then the cycle of incremental additions is to add features  
instead of adding things you forgot.  Adding value, rather than  
recovering intended functionality that wasn''t foreseen to be needed  
in your views.

Maybe it''s all in my head, but I enjoy adding new functionality more  
than spending time going back and adding backend functionality that  
wasn''t foreseen to be needed by the frontend.

So what am I on about?  Well, I''m having trouble doing just that.  I  
want to do View-Driven-Development by Behavior-Driven-Development,  
but I''m stumped really where to begin.  Ideally I''d like to
see a
tutorial or something that walks though it, or browse through some  
projects using RSpec for the views, but I can''t seem to find any.   
Maybe I''m not looking hard enough or I don''t know where to
look.

Could anyone help me with this?

Nathan "fowlduck" Sutton

P.S. Excerpt from my crappy blog, if it matters, http:// 
www.saynotomilk.com/

On 7/29/07, Nathan Sutton <nathan.sutton at gmail.com>
wrote:
> I want to do View-Driven-Development by Behavior-Driven-Development,
> but I''m stumped really where to begin.  Ideally I''d like
to see a
> tutorial or something that walks though it, or browse through some
> projects using RSpec for the views, but I can''t seem to find any.
> Maybe I''m not looking hard enough or I don''t know where
to look.
http://blog.davidchelimsky.net/articles/2006/11/06/view-spec-tutorial

Cheers,
David

Dear Nathan,

What you are sayiing is correct, and in terms of Ruby on Rails, BDD
_IS_ View Driven development... or at least it should be IMHO.

At the end of the day, the only thing that matters in a Rails App is
the Behaviour shown to the user, who has as their only interface, the
View.

The user can not and should not interact with any models.  The user
MIGHT interact with a controller... (say, having a file download which
doesn''t get sent through a view), but really... views ARE the
behaviour of a Rails App.

I found the same thing as you... started with spec''ing my models,
doing great, getting to controllers.. doing OK... getting to views and
going "Where did I go wrong?"

Starting with views and working "backwards" from a Test::Unit point of
view has definately opened up a lot of RSpec doors for me.

My $0.02.

Mikel


On 7/29/07, David Chelimsky <dchelimsky at gmail.com>
wrote:
> On 7/29/07, Nathan Sutton <nathan.sutton at gmail.com> wrote:
> > I want to do View-Driven-Development by Behavior-Driven-Development,
> > but I''m stumped really where to begin.  Ideally I''d
like to see a
> > tutorial or something that walks though it, or browse through some
> > projects using RSpec for the views, but I can''t seem to find
any.
> > Maybe I''m not looking hard enough or I don''t know
where to look.
>
> http://blog.davidchelimsky.net/articles/2006/11/06/view-spec-tutorial
>
> Cheers,
> David
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On 7/30/07, Mikel Lindsaar <raasdnil at gmail.com>
wrote:
>
> Dear Nathan,
>
> What you are sayiing is correct, and in terms of Ruby on Rails, BDD
> _IS_ View Driven development... or at least it should be IMHO.
>
> At the end of the day, the only thing that matters in a Rails App is
> the Behaviour shown to the user, who has as their only interface, the
> View.
>
> The user can not and should not interact with any models.  The user
> MIGHT interact with a controller... (say, having a file download which
> doesn''t get sent through a view), but really... views ARE the
> behaviour of a Rails App.
>
> I found the same thing as you... started with spec''ing my models,
> doing great, getting to controllers.. doing OK... getting to views and
> going "Where did I go wrong?"
>
> Starting with views and working "backwards" from a Test::Unit
point of
> view has definately opened up a lot of RSpec doors for me.
>
> My $0.02.
>
> Mikel

I think one thing that would make view first development a really powerful
tool with rspec is a way to keep track of erroneous calls to model methods.


One thing that I am consistently worried about is specing a method in one
place via mocks, a la the view, but forgetting to include that method in the
model.

The way I get around this at the moment, is when I find a method that I want
to have that isn''t there yet, I open up the spec for the model and add
an
it "should have method bla"

so that it shows up in the pending report.  Of course this means that I have
to have the model spec all setup in the first place kind of defeating the
purpose of view first.  Well almost.  If the view is generated via an rspec
generator then all that is setup.

What would be fantastic is if mock had an option to report calls to
non-existent methods.

Something like mock( User, :report_pending_methods => :true )

Is there another way to do this that is already in practice?

Cheers
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20070730/5d218f2d/attachment.html

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

Regards

Mikel

On 7/30/07, Daniel N <has.sox at gmail.com> wrote:
>
>
> On 7/30/07, Mikel Lindsaar <raasdnil at gmail.com> wrote:
> > Dear Nathan,
> >
> > What you are sayiing is correct, and in terms of Ruby on Rails, BDD
> > _IS_ View Driven development... or at least it should be IMHO.
> >
> > At the end of the day, the only thing that matters in a Rails App is
> > the Behaviour shown to the user, who has as their only interface, the
> > View.
> >
> > The user can not and should not interact with any models.  The user
> > MIGHT interact with a controller... (say, having a file download which
> > doesn''t get sent through a view), but really... views ARE the
> > behaviour of a Rails App.
> >
> > I found the same thing as you... started with spec''ing my
models,
> > doing great, getting to controllers.. doing OK... getting to views and
> > going "Where did I go wrong?"
> >
> > Starting with views and working "backwards" from a
Test::Unit point of
> > view has definately opened up a lot of RSpec doors for me.
> >
> > My $0.02.
> >
> > Mikel
>
> I think one thing that would make view first development a really powerful
> tool with rspec is a way to keep track of erroneous calls to model methods.
>
> One thing that I am consistently worried about is specing a method in one
> place via mocks, a la the view, but forgetting to include that method in
the
> model.
>
> The way I get around this at the moment, is when I find a method that I
want
> to have that isn''t there yet, I open up the spec for the model and
add an
> it "should have method bla"
>
> so that it shows up in the pending report.  Of course this means that I
have
> to have the model spec all setup in the first place kind of defeating the
> purpose of view first.  Well almost.  If the view is generated via an rspec
> generator then all that is setup.
>
> What would be fantastic is if mock had an option to report calls to
> non-existent methods.
>
> Something like mock( User, :report_pending_methods => :true )
>
> Is there another way to do this that is already in practice?
>
> Cheers
> Daniel
>
>
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On 7/30/07, Mikel Lindsaar <raasdnil at gmail.com>
wrote:
> Dear Nathan,
> Starting with views and working "backwards" from a Test::Unit
point of
> view has definately opened up a lot of RSpec doors for me.
I''ve definitely seen advice to start with models before, but
I''ve not
seen anything that says "if you''re using Test::Unit, you should
start
with models". It''s more a development philosophy than a tool
issue.

Cheers,
David

David, true :)

I think I was more mixing up "Test::Unit" and the unit directory under
test in terms of Rails... the unit tests are to the models... ergo...
my definitions were mixed up :)

Anyway... back to coding :)

Mikel

On 7/30/07, David Chelimsky <dchelimsky at gmail.com>
wrote:
> On 7/30/07, Mikel Lindsaar <raasdnil at gmail.com> wrote:
> > Dear Nathan,
> > Starting with views and working "backwards" from a
Test::Unit point of
> > view has definately opened up a lot of RSpec doors for me.
>
> I''ve definitely seen advice to start with models before, but
I''ve not
> seen anything that says "if you''re using Test::Unit, you
should start
> with models". It''s more a development philosophy than a tool
issue.
>
> Cheers,
> David
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On 7/30/07, Mikel Lindsaar <raasdnil at gmail.com>
wrote:
> David, true :)
>
> I think I was more mixing up "Test::Unit" and the unit directory
under
> test in terms of Rails... the unit tests are to the models... ergo...
> my definitions were mixed up :)
Makes sense.

Thanks for playing.

Cheers,
David
>
> Anyway... back to coding :)
>
> Mikel
>
> On 7/30/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 7/30/07, Mikel Lindsaar <raasdnil at gmail.com> wrote:
> > > Dear Nathan,
> > > Starting with views and working "backwards" from a
Test::Unit point of
> > > view has definately opened up a lot of RSpec doors for me.
> >
> > I''ve definitely seen advice to start with models before, but
I''ve not
> > seen anything that says "if you''re using Test::Unit, you
should start
> > with models". It''s more a development philosophy than a
tool issue.
> >
> > 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
>

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 think it would need to do a bit more.

If I call mock_model( User ) and the User class doesn''t exist yet that
will
blow it up.

I guess at that point you would need to create the User class. :(
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20070730/0034b1ff/attachment.html

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?

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, and also keep track of alive?
being decalred on the Thing instance?

-Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20070730/f78d7756/attachment.html

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.

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

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

-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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20070730/4022c59b/attachment-0001.html

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
>

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

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, 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.
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 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
> >
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

> 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....)  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?

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

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
>

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

> 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.
Hmm... great discussion!

The way you are talking sounds, actually, like the right way to do it
in RSpec... vertical slices....

That way you are integrating (somewhat) at the same time as describing
the behaviour of each layer on the way down.

So, really, from one point in the view, you might have four or five
vertical slices described on the way down... and that would tend to
integrate itself somewhat through the process.

Food for thought :)

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 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
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On 30 Jul 2007, at 12:10, David Chelimsky wrote:
> I''ve definitely seen advice to start with models before, but
I''ve not
> seen anything that says "if you''re using Test::Unit, you
should start
> with models". It''s more a development philosophy than a tool
issue.
I see this debate come round now and again.  I can see the  
perspective of view-driven development proponents, but I''ve always  
thought that the models are your, well, model of your problem domain,  
and that you need to understand that before you can create a  
consistent interface.  Maybe this is because most of the work we do  
here is finance-related, and untangling the web of business  
relationships and deals and terms is a nightmare and not something  
you want to keep re-doing.  Perhaps the advice to start with views  
applies more to sites where the view *is* the behaviour (eg a blog)  
rather where the view is more of a presentation layer?

Ashley

Hello,


Are there are any best pracitces for integration-testing is rspec?
What about tutorials ?

I found only http://wincent.com/knowledge-base/ 
Using_Watir_with_RSpec_and_Rails


Chears

Hussein

On 8/2/07, Hussein Morsy <hussein at morsy.de>
wrote:
> Hello,
>
> Are there are any best pracitces for integration-testing is rspec?
> What about tutorials ?
>
> I found only http://wincent.com/knowledge-base/
> Using_Watir_with_RSpec_and_Rails
We''re working on getting the rbehave story runner merged into rspec
and able to integrate w/ rails, but that''s probably a couple of months
away from reality.

Right now I just use rails integration testing and spec/ui to drive
in-browser tests with Selenium or Watir.
>
> Chears
>
> Hussein
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

>
> We''re working on getting the rbehave story runner merged into
rspec
> and able to integrate w/ rails, but that''s probably a couple of
months
> away from reality.
nice to hear :-)


> Right now I just use rails integration testing and spec/ui to drive
> in-browser tests with Selenium or Watir.
To you have an example how to use spec/ui ?


>>
>> Chears
>>
>> Hussein
>>
>>
>> _______________________________________________
>> 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

>
> We''re working on getting the rbehave story runner merged into
rspec
> and able to integrate w/ rails, but that''s probably a couple of
months
> away from reality.
>
nice to hear :-)



> Right now I just use rails integration testing and spec/ui to drive
> in-browser tests with Selenium or Watir.
>
To you have an example how to use spec/ui ?



>>
>> Chears
>>
>> Hussein
>>
>>
>> _______________________________________________
>> 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
>

On 8/2/07, Hussein Morsy <hussein at morsy.de>
wrote:
> >
> > We''re working on getting the rbehave story runner merged into
rspec
> > and able to integrate w/ rails, but that''s probably a couple
of months
> > away from reality.
> >
>
> nice to hear :-)
>
>
>
>
> > Right now I just use rails integration testing and spec/ui to drive
> > in-browser tests with Selenium or Watir.
> >
>
> To you have an example how to use spec/ui ?
There are examples in the spec/ui directory tree:

svn co svn://rubyforge.org/var/svn/rspec/trunk/spec_ui
>
>
>
>
> >>
> >> Chears
> >>
> >> Hussein
> >>
> >>
> >> _______________________________________________
> >> 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
> >
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>