Rspec — Use mocks in the proper way

Setup

Nobody likes when the controller contains too much business logic and becomes fat. Let's start with one simple controller:

class ReservationsController < ActionController::Base
def create
book = Book.available.find_by(isbn: params[:isbn])

if book
BookReservation.create(user: current_user)
book.update(available_count: book.available_count--)

render :success
else
render :not_found
end
end
end

We have an easy solution to this problem. Extract business logic into a separate Service object and call it from the controller. Before starting the refactoring we should write specs. Always check for specs before the refactoring! Fortunately, we already have them

RSpec.describe ReservationsController, type: :controller do
describe 'POST create' do
subject { post :create, params: { isbn: book.isbn } }
context 'when book is not available' do
let(:book) { create(:book, available_count: 0) }
it { is_expected.to render :not_found }
end
context 'when book is not available' do
let(:book) { create(:book, available_count: 1) }
it { is_expected.to render :success}
end
end
end

Refactoring

Ok, we moved business logic into a separate class and added specs for this class. Our controller becomes much slimmer and performs only rendering work.

class ReservationsController < ActionController::Base
def create
ReserveBook.new(params[:isbn]).call
render :success
rescue ReserveBook::Failed
render :not_found
end
end

Our controller was not touched and creates the whole universe to perform tests. Moreover, the same context is created in specs for the controller and service object. There are several options for how we can handle it. The first option, we can extract code into shared_context and use it in both cases. However, didn’t I say that the controller should perform only rendering 😞

Holy Grail?

The second option, here when mocks enter the stage.

RSpec.describe ReservationsController, type: :controller do
describe 'POST create' do
subject { post :create, params: { isbn: 'isbn' } }
context 'when service returns failure' do
before do
allow_any_instance_of(
ReserveBook::Failed
).to receive(:call).and_raise(ReserveBook::Failed)
end
it { is_expected.to render :not_found }
end
context 'when service returns success' do
before do
expect_any_instance_of(
ReserveBook
).to receive(:call).and_return(:ok)
end
it { is_expected.to render :success}
end
end
end

We decouple from the service logic. It is a black box for us, so I don’t want to care about the correct setup of the context. However, there are still several issues. The spec above might pass or not. 😆 Why? It still calls real new that might need the real context.

...
allow(ReserveBook::Failed).to receive(:new).and_return(service)
let(:service) { double }
context 'when service returns failure' do
before do
allow(double).to receive(:call).and_raise(ReserveBook::Failed)
end
it { is_expected.to render :not_found }
end
...

Punchline

But what if someone decides to add some parameters for call? Spec still will pass. That’s why rspec introduced verified mocks instance_double and class_double. They work the same as regular `double`, but also check whether a called message exists and accepts the same list of parameters. We will use both this double, cause not only call notations might be changed but new also.

...
let(:service_class) { class_double(ReserveBook, new: service) }
let(:service) { instance_double(ReserveBook) }
context 'when service returns failure' do
before do
allow(double).to receive(:call).and_raise(ReserveBook::Failed)
end
it { is_expected.to render :not_found }
end
...

Conclusion

We removed business logic from the controller, didn’t repeat yourselves in spec, protected specs from notation changes of the extracted service object.

Worth mentioning that mocks should be used with caution because we are in Ruby and verified double do not protect us from changing the order of the parameters.