Mocking is a form of global state like others (including ENV sharing), which will cause difficulties here (more with threads, a bit less with forks).

let(:warden) do instance_double('Warden::Proxy').tap do |warden| allow(warden).to receive(:authenticate!).with(scope: :user) .and_return(authenticated?) allow(warden).to receive(:user).with(:user).and_return(user) end end let(:user) { instance_double(User) } let(:authenticated?) { true } def simulate_running_with_devise stub_const( 'Rack::MockRequest::DEFAULT_ENV', Rack::MockRequest::DEFAULT_ENV.merge('warden' => warden), ) end

This helper allows you to mock any step within a given or deeply nested activities.

To skip processing inside :load_user and use a mock instead, use mock_step.

When you mock something, you're making a trade-off. You're trading confidence for something else. For me, that something else is usually practicality — meaning I wouldn't be able to test this thing at all, or it may be pretty difficult/messy, without mocking. (Like in our credit card example.)

The more your tests resemble the way your software is used, the more confidence they can give you.

I don't recommend unit testing stateful components, or components with side-effects. Write functional tests for those, instead, because you'll need tests which describe the complete end-to-end flow, from user input, to back-end-services, and back to the UI. Those tests frequently duplicate any testing effort you would spend unit-testing stateful UI behaviors. You'd need to do a lot of mocking to properly unit test those kinds of components anyway, and that mocking may cover up problems with too much coupling in your component.

The basic principle is that you patch where an object is looked up, which is not necessarily the same place as where it is defined. A couple of examples will help to clarify this.