rspec users - Sep 2010 - [BDD] NoMethodError raised when calling #stub with incorrect parameters

I''m new to RSpec and came across an interesting situation where
calling a stubbed method with different parameters from those
specified, raises a misleading error. Some code to illustrate:

(rspec 1.3.0)

describe Person do
  describe "#greeting" do
    context "using #stub with correct parameters" do
      before(:each) do
        subject.stub(:greeting).with("Nicholas")
      end

      specify { lambda{ subject.greeting("Nicholas") }.should_not
raise_error(NoMethodError) }
    end

    context "using #stub with incorrect parameters" do
      before(:each) do
        subject.stub(:greeting).with("incorrect parameter")
      end
      specify { lambda{ subject.greeting("Nicholas") }.should
raise_error(NoMethodError) }
    end
  end
end

I know this is not a test you would have in reality, but it
illustrates the behaviour. I also have come to the realization that
you should never specify parameters when using the stub command, you
should only use #with on #should_receive.

However, when you have mistakenly done this (like the newbie I am),
tracking down the issue can be a bit painful due to the misleading
exception raised. Should developers be protected against using #with
on #stub, a better exception such as
Spec::Mocks::MockExpectationError, or am I missing something?

I would appreciate hearing you thoughts.

Thank you,
Nicholas

I''m new to RSpec and came across an interesting situation where
calling a stubbed method with different parameters from those
specified, raises a misleading error. Some code to illustrate:

(rspec 1.3.0)

describe Person do
 describe "#greeting" do
   context "using #stub with correct parameters" do
     before(:each) do
       subject.stub(:greeting).with("Nicholas")
     end

     specify { lambda{ subject.greeting("Nicholas") }.should_not
raise_error(NoMethodError) }
   end

   context "using #stub with incorrect parameters" do
     before(:each) do
       subject.stub(:greeting).with("incorrect parameter")
     end
     specify { lambda{ subject.greeting("Nicholas") }.should
raise_error(NoMethodError) }
   end
 end
end

I know this is not a test you would have in reality, but it
illustrates the behaviour. I also have come to the realization that
you should never specify parameters when using the stub command, you
should only use #with on #should_receive.

However, when you have mistakenly done this (like the newbie I am),
tracking down the issue can be a bit painful due to the misleading
exception raised. Should developers be protected against using #with
on #stub, a better exception such as
Spec::Mocks::MockExpectationError, or am I missing something?

I would appreciate hearing you thoughts.

Thank you,
Nicholas

I''m new to RSpec and came across an interesting situation where
calling a stubbed method with different parameters from those
specified, raises a misleading error. Some code to illustrate:

(rspec 1.3.0)

describe Person do
 describe "#greeting" do
  context "using #stub with correct parameters" do
    before(:each) do
      subject.stub(:greeting).with("Nicholas")
    end

    specify { lambda{ subject.greeting("Nicholas") }.should_not
raise_error(NoMethodError) }
  end

  context "using #stub with incorrect parameters" do
    before(:each) do
      subject.stub(:greeting).with("incorrect parameter")
    end
    specify { lambda{ subject.greeting("Nicholas") }.should
raise_error(NoMethodError) }
  end
 end
end

I know this is not a test you would have in reality, but it
illustrates the behaviour. I also have come to the realization that
you should never specify parameters when using the stub command, you
should only use #with on #should_receive.

However, when you have mistakenly done this (like the newbie I am),
tracking down the issue can be a bit painful due to the misleading
exception raised. Should developers be protected against using #with
on #stub, a better exception such as
Spec::Mocks::MockExpectationError, or am I missing something?

I would appreciate hearing you thoughts.

Thank you,
Nicholas