On 2010-07-19 5:38 AM, Wincent Colaiuta wrote:
El 19/07/2010, a las 10:58, Matt Wynne escribió:
On 18 Jul 2010, at 00:10, David Chelimsky wrote:
On Jul 17, 2010, at 1:18 PM, Costa Shapiro wrote:
Hello,
I've been thinking of how to express my idea in code, but since I've never been
involved in RSpec development, I'd better have some feedback here first.
The feature suggestion below applies to any controller-like code under spec,
i.e. a stateless module producing output or just altering its data store (it
doesn't necessarily have to be a C of the MVC, but I suppose merb/rails
developers will particularly appreciate it).
Here is a skimmed sample to illustrate the pain:
describe BookController do
context "registering a book" do
specify "from a new author on a new subject" do
auth = mock(:name => 'John Doe')
Author.should_receive(:find_
by_name).and_return(nil)
Author.should_receive(:new).and_return(auth)
auth.should_receive(:save).and_return(true)
subj = mock(:short => 'Mockery')
Subject.should_receive(:find_by_short).and_return(nil)
Subject.should_receive(:new).and_return(subj)
subj.should_receive(:save).and_return(true)
title = 'Specs on Steroids'
book = mock
Book.should_receive(:new).and_return(book)
book.should_receive(:save).and_return(true)
post :register :author => auth.name, :title => title, :subject =>
subj.short
response.should be_success
end
specify "from a known author on a new subject" do
auth = mock(:name => 'Joe Dohn')
Author.should_receive(:find_by_name).and_return(auth)
subj = mock(:short => 'Mockery')
Subject.should_receive(:find_by_short).and_return(nil)
Subject.should_receive(:new).and_return(subj)
subj.should_receive(:save).and_return(true)
title = 'Specs on Steroids II'
book = mock
Book.should_receive(:new).and_return(book)
book.should_receive(:save).and_return(true)
post :register :author => auth.name, :title => title, :subject =>
subj.short
response.should be_success
end
specify "from a known author on a known subject" do
auth = mock(:name => 'Joe Dohn')
Author.should_receive(:find_by_name).and_return(auth)
subj = mock(:short => 'Forgery')
Subject.should_receive(:find_by_short).and_return(subj)
#...
end
specify "from a new author on a known subject" do
#...
end
end
end
And this is what I have in mind for doing exactly the same job:
describe BookController do
context "registering a book" do
before :any, "from a new author", :author do
@auth = mock(:name => 'John Doe')
Author.should_receive(:find_by_name).and_return(nil)
Author.should_receive(:new).and_return(@auth)
@auth.should_receive(:save).and_return(true)
end
before :any, "from a known author", :author do
@auth = mock(:name => 'Joe Dohn')
Author.should_receive(:find_by_name).and_return(@auth)
end
before :any, "on a new subject", :subject do
@subj = mock(:short => 'Mockery')
Subject.should_receive(:find_by_short).and_return(nil)
Subject.should_receive(:new).and_return(@subj)
@subj.should_receive(:save).and_return(true)
end
before :any, "on a known subject", :subject do
@subj = mock(:name => 'Joe Dohn')
Subject.should_receive(:find_by_name).and_return(@subj)
end
it "should succeed", :with => [:author, :subject] do
title = 'Specs on Steroids X'
post :register :author => @auth.name, :title => title, :subject =>
@subj.short
response.should be_success
end
end
end
A run of such specs will effectively multiply the tests — automatically —
choosing before and after blocks as specified.
I'm sorry, I haven't thought the DSL through, but I hope the main idea can be
seen: contexts do not have to be hierarchical.
In my opinion, adding some sort of context selection+combination capabilities
(AOP-style) will contribute greatly to the expressiveness of the spec language.
I think the idea of mixing/matching sub-contexts is very interesting, but it
definitely needs from fleshing out. It would have to be easy to read/understand
in the spec file as well as the output.
Also, this only works if every combination should behave the same way. I think we'd need
a means of saying "given these combinations of data, expect these outcomes".
Anybody else have thoughts on this?
It's a nice idea.
I'm not sure whether I'd use it though. I think this idea comes from the desire
to write specs that are *complete*, which I can perfectly understand but I
don't think I subscribe to anymore. I prefer to really craft the examples so
there's 'just enough' tests but no more than that. I'd be worried this might
offer a temptation to think less about why you're writing each example, and I'd
be worried how that would help me to do TDD.
It should be possible to do something like this using macros now, right? Can I
suggest that the OP has a go at refactoring his code using macros and we can
see how it looks?
I know that the posted code may be a contrived toy example for the purposes of
illustration, but when I see a spec like that alarm bells start to ring. So
much mocking, so many assertions in each example block etc. And it's not at all
clear what the pertinent behavior is that you want to test here, because each
example looks exactly like a one-to-one rewrite of the original implementation
that uses mocks instead of real objects.
And when the alarm bells start to ring, before I think about changing my
testing framework to make things easier, I look at the code under test to see
if it could be changed to be more testable.
So we basically have a controller action that accepts three parameters (author,
title, and subject), and it has a conditional code path for two of those:
if thing.exists
great
else
create it
end
And in your spec you're wanting to test for all the different permutations of
new author/existing author and new subject/existing subject.
First thing you could do to eliminate a lot of mocking is use something like
"find_or_create_by_name" and "find_or_create_by_short". Then you only have to
mock three calls (one for each parameter) and forget about the permutations entirely.
This is an example of pushing logic down into the model in order to make controllers
simpler and more testable. If "find_or_create_by_*" doesn't do what you need it
to, then create a model method which does.
You could go even further and create a "register" method on your Book class
which accepted the three parameters of author, title, and subject, and did everything
which you are currently doing in your controller in the model layer instead. Then your
controller spec becomes ridiculously simple, can be tested with a single mock, and the
rest of the logic now resides in a model, which is easily testable.
So whether or not the example was a toy example, the need for the any automatic
permutation and spec generation in RSpec has disappeared. Let's imagine,
however, that the need was still there. Would adding this kind of code to RSpec
itself be a good idea?
I don't necessarily think so. Matt says you can probably do this right now by
using macros. I don't actually know what he means by that, but I do know that
there are cases where I sometimes want a bunch of nearly identical specs, and I
generate them in code using enumeration or some other means; ie. dumb example:
[:foo, :bar, :baz].do |thing|
describe "#{thing} dimensions" do
it 'has length' do
thing.to_s.length.should> 0
end
end
end
Glad to see I'm not the only one that does this. :)
Peace,
Phillip
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
