gistfile1.rb

require 'spec_helper'

describe SharesController do
  render_views

  describe '#create' do

    it "should redirect to Login if user is not logged in" do
      post :create, :share => { :facebook_id => 'abc', :address_id => 7 }
      response.should redirect_to login_path
    end

    it "should create a new Share if called correctly" do
      user = login_user
      share = Share.new(:user_id => user.id, :facebook_id => 'abc', :address_id => 7)
      Share.should_receive(:new).once.with(:user_id => user.id, :facebook_id => 'abc', :address_id => 7).and_return(share)
      share.should_receive(:save).once.and_return(true)
      post :create, :format => :json, :share => { :facebook_id => 'abc', :address_id => 7 }
    end

    it "should respond with success if no error occured" do
      user = login_user
      share = Share.new(:user_id => user.id, :facebook_id => 'abc', :address_id => 7)
      Share.should_receive(:new).once.with(:user_id => user.id, :facebook_id => 'abc', :address_id => 7).and_return(share)
      share.should_receive(:save).once.and_return(true)
      post :create, :format => :json, :share => { :facebook_id => 'abc', :address_id => 7 }
      response.should be_success
    end

  end
end

"if called correctly"

• why do you mock the object creation instead of checking for a count increment? (my guess: to circumvent/make the test independent from validation. understandable, but feels hacky.)
• since you mock the object initialization anyway (line 16), why do you bother to initialize your share object with the same parameters (line 15) that your request sends? you could use just anything for the share object (a string, for example) to make clear that the controller doesn't care at all about the internal workings of that object, except that it must be able to initialize and save it, whatever it is.
• i'm missing a counterexample (what would "not correctly" mean and what would the expected behavior be?).

"if no error occurred"

• what kind of errors could occur under which circumstances and what is the expected behavior?
• why do you mock the share creation here? it seems to be independent from what the descriptions says the example is supposed to test. in its current implementation, this test looks so much like a duplicate of the previous test, that it doesn't seem to pay for the lines of code it occupies.

contexts

example two and three share the context of a user being logged in. the login itself should not be part of the test but belongs to the shared setup of the context.

• why do you mock the object creation instead of checking for a count increment? (my guess: to circumvent/make the test independent from validation. understandable, but feels hacky.)
  • Mh, not quite sure if this is hacky. I'm quite hardcore about the "test only your code!" approach, that is, I want to make sure I only test the behaviour of the Controller, not the Model. The behaviour I expect from my Controller is to instantiate the Share model and use it in a specific way
• since you mock the object initialization anyway (line 16), why do you bother to initialize your share object with the same parameters (line 15) that your request sends? you could use just anything for the share object (a string, for example) to make clear that the controller doesn't care at all about the internal workings of that object, except that it must be able to initialize and save it, whatever it is.
  • I agree
• i'm missing a counterexample (what would "not correctly" mean and what would the expected behavior be?).
  • True, not yet implemented
• what kind of errors could occur under which circumstances and what is the expected behavior?
  • Same here, I need to add this
• why do you mock the share creation here? it seems to be independent from what the descriptions says the example is supposed to test. in its current implementation, this test looks so much like a duplicate of the previous test, that it doesn't seem to pay for the lines of code it occupies.
  • Mh... I'm not sure how to ensure the Controller actually works if I'm not mocking the Share object completely. If e.g. share.save would fail, the expected behaviour would be different
  • It's a lot of duplication, that's true - but at the end of the day, it's 2 different behaviours: "Making use of the model" and "returning success". Thought I should go the extra mile and make this distinction in the specs.
• contexts
  • Could you elaborate how to do this with RSpec?

contexts: yes: https://gist.github.com/982618