Question About Cleaning Up Specs?

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

Let me know if that’s good practice

On 18 Feb 2010, at 16:25, [email protected] wrote:

User.should_receive(:find).and_return @user
@post = mock_model(Post)
@user = mock_model(User)

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

Let me know if that’s good practice

That’s exactly what I do.


rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users

cheers,
Matt

http://mattwynne.net
+447974 430184

Joaquin Rivera P. wrote:

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.

Peace,
Phillip

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.

Pat

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,

greetings,
joaquin

2010/2/18 Matt W. [email protected]

On Fri, Feb 19, 2010 at 8:13 PM, Pat M. [email protected]
wrote:

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


Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs