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