Let’s say our side effect needs some safeguarding because it can throw a NoMethodError in some cases. This additional granularity allows future devs to change what the service class does without fear of impacting other tests. Now we are shoveling all new instances of our service through the same double, so RSpec gives us the ✅. describe CoolClass do let(:mocked_cool_class) before do allow(double_class).to receive(:new).and_return(instance) allow(instance).to receive(:some_side_effect) end it 'returns hiya buddy and does something else that we are not worried about right meow' do expect(described_method).to eq('Hiya buddy!') expect(instance).to have_received(:some_side_effect) end context 'when passed in yes' do it 'runs the side effect twice' do expect(described_method('yes')).to eq('Hiya buddy!') expect(instance).to have_received(:some_side_effect).twice end end end If you are an RSpec user the way to accomplish these is to use allow in combination with an instance_double or class_double.Ĭool_class.rb class CoolClass def self.foo 'bar' end endĬool_class_spec.rb require 'rspec' RSpec. By mocking out side effects we are able to test the interface of a single unit (method/worker/service etc.) and ensure that many edge cases can run quickly and consistently. Boundaries need to be drawn in order to accentuate each layer of your testing pyramid. Any system under test needs some degree of mocks.
0 kommentar(er)
