0
我有以下代碼:RSpec的it_behaves_like減少調試知名度
context 'user doesnt exists with that email' do
let(:params) { original_params.merge(login: "[email protected]") }
it_behaves_like '404'
it_behaves_like 'json result'
it_behaves_like 'auditable created'
end
它是乾的,因爲我可以用在其他環境中這些元素,以及:
context 'user exists with that email' do
it_behaves_like '200'
it_behaves_like 'json result'
end
我shared_example是:
...
RSpec.shared_examples "json result" do
specify 'returns JSON' do
api_call params, developer_header
expect { JSON.parse(response.body) }.not_to raise_error
end
end
...
好處是規格更具可讀性並且乾燥。規範失敗指向shared_example文件而不是原始規範。這很難調試。發生在login_api_spec 以下錯誤:25,但這是rspecs輸出:
rspec ./spec/support/shared_examples/common_returns.rb:14 # /api/login GET /email user doesnt exists with that email behaves like 401 returns 401
任何好的建議如何繼續寫乾燥和便於調試rspec的?
沒有共享的例子的代碼將是更長的時間,不容易閱讀:
context 'user doesnt exists with that email' do
let(:params) { original_params.merge(login: "[email protected]") }
specify "returns 404" do
api_call params, developer_header
expect(response.status).to eq(404)
end
specify 'returns JSON' do
api_call params, developer_header
expect { JSON.parse(response.body) }.not_to raise_error
end
specify 'creates an api call audit' do
expect do
api_call params, developer_header
end.to change{ EncoreBackend::ApiCallAudit.count }.by(1)
end
end
我有成千上萬的RSpec的測試,像這樣的所以它是非常有利於共享的例子寫的規格,因爲它是快寫,但調試很難。