I know we are suppose to keep specs obvious and readable, but is it
normal (or there any opposition) to stubbing every method call that
you needed in a before block and simply over-riding the same method
with a should_receive in the actual tested it()?
Example
describe “#create” do
it “should find a user” @user = mock_model(User)
User.should_receive(:find).and_return @user @posts = [] @post = mock_model(Post) @posts.stub(:build).and_return @post
post “create”
end
it “should build a post from that user” do @user = mock_model(User)
User.stub(:find).and_return @user @posts = [] @post = mock_model(Post) @posts.should_receive(:build).and_return @post
post “create”
end
end
… would become …
describe “#create” do
before do @user = mock_model(User)
User.stub(:find).and_return @user @posts = [] @post = mock_model(Post) @posts.stub(:build).and_return @post
end
it “should find a user”
User.should_receive(:find).and_return @user
post “create”
end
it “should build a post from that user” do @posts.should_receive(:build).and_return @post
post “create”
end
end
Note that I stubbed both method calls in the before, but only
should_require’d them in the appropriate it()?
On 18 Feb 2010, at 16:25, [email protected]
describe "#create" do
@user = mock_model(User)
User.should_receive(:find).and_return @user
post "create"
end
it "should build a post from that user" do
@posts.should_receive(:build).and_return @post
post "create"
end
end
I often have a before :each that initializes objects to some default
state and then change whatever is necessary in the individual examples.
+1 here as well.
I disagree with the crowd on the basis that these examples are lazy.
Very close to what I do though.
Imagine you had one other example in there:
it “should assign the post to the view” do
post :create
assigns[:post].should == @post
end
Then you wouldn’t really need the other should_receive examples. Why?
Well, there’s no way for that object to be returned other than via your
User.find().build chain, is there?
I would still write the should_receive’s, but they would include the
arguments I expect the method to receive. That’s the point where
something could get screwed up.
But hopefully you can see why, if you’ve created a chain of stubbed
methods, you only need to verify the end result of the chain, and
everything up to it is verified implicitly.
those who knows more say the idea is to keep in the example only what is
important for the example (but they surely say it even better than me)
which
is what you are doing +1,
I disagree with the crowd on the basis that these examples are lazy. Very close to what I do though.
Imagine you had one other example in there:
it “should assign the post to the view” do
post :create
assigns[:post].should == @post
end
Then you wouldn’t really need the other should_receive examples. Why? Well, there’s no way for that object to be returned other than via your User.find().build chain, is there?
Well actually you’d need a User.find().build chain which arranged for
the stub @user to return @posts from a call to posts.
I would still write the should_receive’s, but they would include the arguments I expect the method to receive. That’s the point where something could get screwed up.
Right, you would want to prove that you were finding the right user in
this case, although I’d guess in most conventional rails apps these
days you’d actually stub the controllers current_user method to return @user rather than stubbing User.find