Reading user input in console applications is usually done using Kernel#gets. Stubbing that can be a bit hairy. When your code expects user input, you can not say Kernel.stub...

Object.any_instance.stub(gets: 'user input') Any instance of an object should eventually hit that stub...

If you stub a method or set expectations with should_receive these stubbed methods may also yield blocks. This is handy if the returning object is receiving a block call...

it 'should process messages in batches so the server stays alive' do message = stub message.should_receive(:crawl) Message.should_receive(:find_in_batches).and_yield([message]) subject.crawl_messages end

...describe '.distance' do it 'should work for edge case zero-distance computation' do from = stub :latitude => BigDecimal('0.4991657542 5E2'), :longitude => BigDecimal('-0.1169188713 5E3') to = stub :latitude => BigDecimal('0.4991657542 5E2'), :longitude...

...in a previous request. Working around the issue You can avoid that behavior by stubbing the controller's session and querying that stub: persisted_session = ActionController::TestSession.new controller.stub :session => persisted...

persisted_session[:something].should ... Apply this workaround only when you need it. Stubbing controller.session is not entirely the same, but good enough in most cases. Example

...receive(:current_plan).and_return plan end context 'when expiring today' do let(:plan) { stub(:expiry => Date.today) } it 'should be false' do subject.should_not be_locked end end context 'when...

...expired yesterday' do let(:plan) { stub(:expiry => Date.yesterday) } it 'should be true' do subject.should be_locked end end end end Note this does not work for local variables you set...

...method value of the current subject: describe Array do its(:length) { should == 0 } end stub_chain is the tie to go along with should_receive_chain's tux: object.stub_chain...

...first, :second, :third).and_return(:this) You can restore the original implementation of stubbed methods with unstub: object.stub(:foo => 'bar') # ... object.unstub(:foo) In recent RSpecs double is the preferred way...

You can configure RSpec 3.3+ to raise an error when attempting to stub or mock a non-existing method. We strongly recommend to do this as non-verified stubs are...

...with :rspec do |mocks| mocks.verify_partial_doubles = true end end This will also replace stub_existing from our rspec_candy...

We often use VCR to stub external APIs. Unfortunately VCR can have problems matching requests to recorded cassettes, and these issues are often hard to debug. VCR's error messages...

...you should at least confirm these aspects work flawlessly: DB connection, Redis, memoization, spec stubs, Rake tasks like rake parallel:prepare

savon.expects(:action_name).with(message: { user_id: 123 }).returns(' ') If you want to stub only the returned XML and do not care about request arguments, you can not omit...

describe '#index' do it 'should be able to send an excel file' do # stubs and expectations go here get :index, :format => 'xls' end end end Remember that both the...

...without having an external worker running. For this, you could use ResqueSpec which basically stubs away Resque completely. If you don't want that, but more closely mimic what actually...

} } ) This is roughly equivalent to this in Javaland, where you have magic generated stub code: SomeObject so = new SomeObject(); so.setName('foo'); so.setOther('bar'); client.rpcMethod(so...

Using VCR to record communication with remote APIs is a great way to stub requests in tests. However, you may still want to look at the request data like the...

This finally works: User.any_instance.should_receive(...) as does User.any_instance.stub(...) Note: You won't have RSpec 2.6 if you're still working...