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